Build Systems

[Bart]

Bart:
>> Suppose you dispensed with all that dependency stuff; how long would
>> it take to build such a project? Say compared with just compiling one
>> module.
>>

David Brown:

> That particular project takes a minute and a half to compile on my
> laptop (it's faster on my main machine). It's 373 compilations, perhaps
> 40% of it C++. Too long for convenience.

OK. I'm surprised (since you say you work on embedded systems) that
software for those can be so elaborate.

I've worked with some restricted machines, and my program builds, which
were also done ON those machines (no cross-compiler on a bigger
machine!) has never taken anywhere near as long as that.

But I thought, should I give 'make' one more chance? I tried some
smallish projects:

-----------------------------
Pico C interpreter: This has a makefile, but it was for Linux. A Windows
build requires MSVC and VS (or whatever is needed to deal with .sln
files), so no thanks.

Yet, I have built this project in the past without make or VS, once I'd
extracted the necessary info.

-------------------------------------------------

Lua Interpreter: This had a makefile, but gave errors. A closer look
revealed things like "-DLINUX...". I know this builds on Windows, but
there was no info as to how that I could see.

----------------------
8cc C compiler: Linux only (although this wasn't mentioned; unistd.h in
the sources gave a clue).

------------------------

SubC C Compiler: this uses a makefile file, but also has WINBUILD.BAT
for Windows. I guess make was not quite flexible enough for Windows, or
had too many Linux dependencies.

But WINBUILD didn't quite work. Maybe it was to do with some errors
unpacking 2-3 .tgz/.tar files: 'Cannot create symbolic link: a required
privilege...'.

--------------

So, maybe 'make' can work under Windows, if only I can find a suitable
project where that actually happens!

What I did find was build systems that are chaotic; the above are
typical unfortunately.

'make' is only part of the problem. Yet these projects are quite
small-scale, with dozens of source files, compared with gcc 13.2 which
had 75,000 source files, and that was described by two people here as
being simple to build.

DB:
> Computers are good at tedious work. They are good at tracking this kind
> of small detail. Why not let the computer do the work here?

Exactly. But I'm not seeing that in these projects. Somebody has to go
to a lot of trouble to create those build scripts, or get additional
sofware's help to create them. Which in the end did not result in my
being able to do an effortless, trouble-free build.

>All it takes is a little googling and a willingness to learn -
makefiles have a somewhat cryptic syntax,

And here you confirm what I said!

>Longer does not mean better. Often it means set in your ways, and
unwilling to look at alternatives.

On the contrary. Alternatives are EXACTLY what I have always worked on,
especially over the last decade.

Maybe it's /you/ who's unwilling to looked at alternatives, but are too
locked in to existing languages, compilers, OSes and support tools. Such
a critical mass has been created that there is no easy way out; just
piling on more stuff, finding creative ways to make things faster.

My C compiler project is roughly on the same scale as the above
examples. Somebody sitting at my desk right now wanting to build my C
compiler would type this from inside the project folder:

C:\cx>mm cc

The project is 71 source and support files, spread this plus two further
nested folders (these contain my compiler's standard headers and
reflects their structure).

The folders contain other stuff not necessary for the build; it doesn't
matter. /Some/ might be junk, a lot is needed for development.

If you wanted to build this product, I could supply a ZIP with a clean
set of files. It would also contain mm.exe, the compiler needed. (Oh
yes, my C compiler is not written in C.)

However, what I would probably do instead is this:

C:\cx>mm -ma cc

This creates an amalgamated file cc.ma. Now I just email you mm.exe and
cc.ma, and you just type:

Anywhere> mm cc.ma # .ma is optional if no clashes

Maybe you'd rather compile C source code instead? OK, I would then do:

C:\cx>mc -c cc # Transpile to single C file

And email you just the cc.c file. You can build it on Windows like this
(add your own options to taste):

Anywhere> gcc cc.c # (tcc needs extra options)

This builds a self-contained C compiler called a.exe. Does it work? I'll
try it:

C:\cx>a cc
Compiling cc.c to cc.exe

But, maybe you want to use Linux? OK, let's see what I can do. I can try
this instead:

C:\cx>mc -c -linux cc m # C file Linux-specific portions

Then, on Linux, you'd need to build it like this demo on WSL:

root@DESKTOP:/mnt/c/cx# gcc cc.c -lm -ldl -fno-builtin -obcc

However, there are limitations, since my C compilers target Win64 ABI,
not Linux. You can do this:

root@DESKTOP:/mnt/c/cx# ./bcc -c sql
Compiling sql.c to sql.obj

root@DESKTOP:/mnt/c/cx# ./bcc -S sql
Compiling sql.c to sql.asm

But you can't create sql.exe (that needs to access msvcrt.dll). And even
those .obj/.asm files contain Windows-specific native code.

-------------------------------

So, what do think of my alternatives? No build system in sight, whether
makefiles, SLN files or batch files.

In each case there was a simple one-line command involving one compiler
and one named source file, even if that line got longer the further we
got from my language, and from Windows.

For an actual multi-file, original C project, I've demonstrated
elsewhere the -auto option of my C compiler. But for use with existing
compilers for other people to use from the command line I would provide
@ or .bat files.

Of course, most of my actual development, not command line work, is from
from my mini-IDE, currently a 75KB program. I can use that for C too but
only bcc is supported.

[Ben Bacarisse]

Bart <b...@freeuk.com> writes:

> But I thought, should I give 'make' one more chance? I tried some smallish
> projects:
>
> -----------------------------
> Pico C interpreter: This has a makefile, but it was for Linux. A Windows
> build requires MSVC and VS (or whatever is needed to deal with .sln files),
> so no thanks.

What has this got to do with make?

> Yet, I have built this project in the past without make or VS, once I'd
> extracted the necessary info.

Did you contribute your method, batch file, makefile or whatever to the
project? If not, why not?

> -------------------------------------------------
>
> Lua Interpreter: This had a makefile, but gave errors.

Linux software, does not compile without effort on Windows. In other
news, bear defecates in the woods.

> A closer look
> revealed things like "-DLINUX...". I know this builds on Windows, but there
> was no info as to how that I could see.

They make it hard. It's hidden on the download page under the heading
"Building" with the confusing link "detailed instructions".

But again, what has this do with make?

> ---------------------- 8cc C compiler: Linux only (although this
> wasn't mentioned; unistd.h in the sources gave a clue).

Again, hidden away in the README file:

"8cc supports x86-64 Linux only. I have no plan to make it
portable..."

Who'd think to look there?

And again, what has this to do with make?

> ------------------------
>
> SubC C Compiler: this uses a makefile file, but also has WINBUILD.BAT for
> Windows. I guess make was not quite flexible enough for Windows, or had too
> many Linux dependencies.

Or maybe the person who wrote the BAT file did not know make? Now if
you had some evidence that a BAT file was needed because make can't do
the job on Windows then you might actually have a comment that relates
to giving make one more try. But you don't.

Your remark about giving make a another try in a post about build
systems suggests you don't know what it's for. It does not magically
allow software to be built on different systems. However, it might
help. While a .BAT file will be of no use on Linux, a well-written
makefile might need only a few tweaks to compile a program with MS VC
and of course it could include a Windows-only target like "prog.exe" so
no that tweaks might be needed.

> --------------
>
> So, maybe 'make' can work under Windows, if only I can find a suitable
> project where that actually happens!

Or you could chip in and help by writing a windows makefile (or adding
suitable rules to a existing makefile) for one of them.

> What I did find was build systems that are chaotic; the above are typical
> unfortunately.

They seem be crying out for someone to write a good Windows makefile
for them. Will that be you?

> 'make' is only part of the problem.

Or make could be a big part of the solution.

--
Ben.

[Bart]

On 13/08/2023 21:45, Ben Bacarisse wrote:

> Bart <b...@freeuk.com> writes:
> What has this got to do with make?

> But again, what has this do with make?

> And again, what has this to do with make?

I'm looking for a project to build on Windows using make. I didn't have
much luck; they seem to avoid using it!

>> Lua Interpreter: This had a makefile, but gave errors.
>
> Linux software, does not compile without effort on Windows. In other
> news, bear defecates in the woods.

Rubbish. Lua had been easy to build: just submit the right set of .c
files to the compiler. Except the next version had a slightly different
set of files.

>> A closer look
>> revealed things like "-DLINUX...". I know this builds on Windows,
but there
>> was no info as to how that I could see.
>
> They make it hard. It's hidden on the download page under the heading
> "Building" with the confusing link "detailed instructions".

Not if you approach it via 'github lua'. There is more info if you go to
the proper Lua site, but I still couldn't see what you are supposed to
do to build Lua using 'make', as that was the purpose of the exercise:
to find even ONE project where make actually works on Windows!


--------------------

I'm going to try one more project, which is Tiny C. This is better
documented, and directly within the downloaded files.

The build process for Linux is './configure' (oh-oh) then 'make', but it
says, for Windows read tcc-win32.txt.

There it says: install MSYS and /then/ do './configure' followed by 'make'!

But then it also gives the choice of running a batch file.

So, another project where they give up on 'make' on Windows. And this is
what you guys want me to adopt? These examples aren't very compelling
are they?

Since I'm at this point, I might as well try that batch file. It relies
on gcc. And ... compiler errors amongst loads of warning and notes.

Disappointing. But if it had worked, configure + makefile together were
654 lines, this batch file was 28 lines.

It presumably contains the right instructions to build this app; what's
with the other 626 lines?

>> What I did find was build systems that are chaotic; the above are
typical
>> unfortunately.
>
> They seem be crying out for someone to write a good Windows makefile
> for them. Will that be you?
>
>> 'make' is only part of the problem.
>
> Or make could be a big part of the solution.

My solutions in the snipped portions are:

* Use a language with its own build system and a built-way to create
one-file amalgamations

* For C, find a way to create (sqlite3-like) one-file amalgamations

* Supply build information as an @ list of files or a /simple/ shell
script (or just explain in English how to build)

* For anything more elaborate, use a script but in a language anyone
understands

Remember for someone else to build a working program from source,
dependencies within a make files are irrelevant.

[Ben Bacarisse]

Bart <b...@freeuk.com> writes:

> On 13/08/2023 21:45, Ben Bacarisse wrote:
>> Bart <b...@freeuk.com> writes:
>> What has this got to do with make?
>> But again, what has this do with make?
>
>> And again, what has this to do with make?
>
> I'm looking for a project to build on Windows using make. I didn't have
> much luck; they seem to avoid using it!

You found a Unix utility hardly used on Windows. Film at 11.

> Remember for someone else to build a working program from source,
> dependencies within a make files are irrelevant.

Yes, make is not a configuration and build system. It does not attempt
to solve any of the issues in your posts on the topic.

A lot of the software you looked at is open source (some of it also free
as in freedom) originating on Linux systems. A key consideration for
such software is to encourage development rather than just building.
That's why make is popular and commonly used in the Linux world.

Things may have changed, but when I used to use Windows a lot, software
was rarely distributed as source code and even more rarely in a form
that encouraged tinkering. If there is a way of doing this, that is
widely used in the Windows world, I don't know what it is.

--
Ben.

[Scott Lurndal]

Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>Bart <b...@freeuk.com> writes:
>
>> On 13/08/2023 21:45, Ben Bacarisse wrote:
>>> Bart <b...@freeuk.com> writes:
>>> What has this got to do with make?
>>> But again, what has this do with make?
>>
>>> And again, what has this to do with make?
>>
>> I'm looking for a project to build on Windows using make. I didn't have
>> much luck; they seem to avoid using it!
>
>You found a Unix utility hardly used on Windows. Film at 11.

As far as I am aware, Windows doesn't have a native make utility in
the first place (nmake is part of the visual studio distribution), so
its likely that Bart's quest to find a package that uses make on
windows will fail.

[Kenny McCormack]

In article <PPeCM.479849$TCKc....@fx13.iad>,

DOS/Windows (and Mac similarly) has *never* shipped with any sort of
development environment, so arguing that it doesn't have "make" is kind of
pointless.

--
https://en.wikipedia.org/wiki/Mansplaining

It describes comp.lang.c to a T!

[Malcolm McLean]

Yes, when I started as a DOS programmer you had to buy a compiler.
I asked for one as a birthday present from my grandmother, and I remember
trying to explain to her what she had just bought me. Then later on I
moved to Windows and bought Visual Studio. It was a lot of money
for me at the time, and was a "personal" copy. It lacked an optimiser, some
group work facilities (I think) and you weren't allowed to sell software compiled
with it. The full version cost several hundred pounds and was out of reach.
But I loved it because of the integrated help (this was pre good internet).

Then they broke it when Vista came out. I compained, and received
an arrogant and dismissive response. I was absolutely furious. The
personal, affordable compilers were discontinued, and only the enterprise
edition available. Which cost more than the computer. There was a free
Visual Studio available, but you could tell that at the time Microsoft
wasn't happy about releasing free software. It was badly done, and difficult
to use, and didn't support the latest C standards, and didn't have proper API
documentation. And it came with ban on using it to develop software
with what they called a "viral" licence.

Nowadays Visual Studio is free even to commercial users. Stallman has
won. But you have to download it. It doesn't ship as standard.

[Kenny McCormack]

In article <8fb22829-9b5e-4108...@googlegroups.com>,
Malcolm McLean <malcolm.ar...@gmail.com> wrote:
...

>> DOS/Windows (and Mac similarly) has *never* shipped with any sort of
>> development environment, so arguing that it doesn't have "make" is kind of
>> pointless.

I may actually have mis-spoken here. DOS did originally come with GWBASIC,
so you could, at least write and run programs back then.

Whether BASIC (of any stripe) counts as a development environment is, of
course, open to debate...

Does modern Windows come with VB.NET ready-to-go, or do you have to
download it?

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/FreeCollege

[Malcolm McLean]

On Monday, 14 August 2023 at 03:44:31 UTC+1, Kenny McCormack wrote:
> In article <8fb22829-9b5e-4108...@googlegroups.com>,
> Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> ...
> >> DOS/Windows (and Mac similarly) has *never* shipped with any sort of
> >> development environment, so arguing that it doesn't have "make" is kind of
> >> pointless.
> I may actually have mis-spoken here. DOS did originally come with GWBASIC,
> so you could, at least write and run programs back then.
>

Yes, when microcomputers came out in the 1980s, it was thought that the
average user would also develop his own programs. So when you booted
the computer it put you into the BASIC. Because the machine was so small,
there wasn't a distinction between the editor and the intepreter.

>
> Whether BASIC (of any stripe) counts as a development environment is, of
> course, open to debate...
>

I'm an implementer of BASIC myself so don't diss the language. MIniBasic, which
is my version, is used in embedded systems. Often the embedded processor is
doing something pretty trivial in programming terms (the interest of the project
is in the electronics). It's easier to edit a short MiniBasic script on the machine
than cross-compile and load an executable.

>
> Does modern Windows come with VB.NET ready-to-go, or do you have to
> download it?
>

You have to download it. VB is still used for serious commercial development.
But for programs where the focus is on the GUI and business logic. It's not
used much for the sort of programming that I do.

[Kaz Kylheku]

MS-DOS came with DEBUG.COM: an assembly language development
environment. :)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazi...@mstdn.ca

[Bart]

There are projects with makefiles that are meant to work with Windows.
IME they mostly don't work, in that something usually goes wrong. I just
couldn't remember what they were.

I do however remember one that did work: LuaJIT. I downloaded it now,
and there, the main makefile has this comment:

# Suitable for POSIX platforms (Linux, *BSD, OSX etc.).
# Note: src/Makefile has many more configurable options.
#
# ##### This Makefile is NOT useful for Windows! #####
# For MSVC, please follow the instructions given in src/msvcbuild.bat.
# For MinGW and Cygwin, cd to src and run make with the Makefile there.

I don't have MSVC (I can rarely get it to work, and it's monstrous).

Mingw I guess means gcc on Windows. When I tried that other makefile, it
worked perfectly. The output messages were also clean and restrained (no
endless crap flying up the screen for an hour, like GMP under MSYS).

But this is rare. My assertion is that they're usually troublesome. I
also don't hold with having to use MSVC when I have a perfectly good
compiler, gcc, even with its foibles.

This project is unusual (or maybe this is common) as it can't really be
built with any compiler. Attempts to use one that's not supported will
display:

lj_def.h:300: error: #error "missing defines for your compiler"

Here it's done properly: helpful messages inside the downloaded files.

[Kenny McCormack]

In article <202308132...@kylheku.com>,
Kaz Kylheku <864-11...@kylheku.com> wrote:
...

>MS-DOS came with DEBUG.COM: an assembly language development
>environment. :)

Indeed. And I used it as such - many times. I also used DEBUG as an editor.

--
12% of Americans think that Joan of Arc was Noah's wife.

[Karl Meyer]

There is a GNU version of Make for Windows. There is also a GNU version of the GCC for Windows that can compile compatible binaries for Window's and x86_x64.

For native Windows apps though, it really doesn't make sense to use it long term, as the MSVC is clearly optimized to leverage the OS and all its features to make programs work efficiently.

Besides the Visual Studio build system that you can configure within the app, if you prefer "lighter" dev environments, its perfectly easy to use VS Code with an off the shelf build system like CMake or PreMake (or even GNU Make) as long as you have a C/C++ compiler already in your System Variables Path (or configured through VS Code's config). What you lose by NOT doing Windows application development inside of Visual Studio is its extremely feature rich Debug suite.

[David Brown]

On 13/08/2023 15:53, Bart wrote:
> Bart:
> >> Suppose you dispensed with all that dependency stuff; how long would
> >> it take to build such a project? Say compared with just compiling one
> >> module.
> >>
>
> David Brown:
>
> > That particular project takes a minute and a half to compile on my
> > laptop (it's faster on my main machine).  It's 373 compilations, perhaps
> > 40% of it C++.  Too long for convenience.
>
> OK. I'm surprised (since you say you work on embedded systems) that
> software for those can be so elaborate.
>

I work on embedded systems - mostly microcontroller systems. But why
would that mean few files in a project? Like most programmers, I
organise my source files and split things up in logical sections. So
even the smallest of programs might have 15 or more C files. And this
particular program is not small, and includes things like a network
stack, an RTOS, and a large number of manufacturer-supplied driver files
in the microcontroller's SDK. The final binary is about 200 KB in size.
Oh, and I was counting compilations, not source files - the "make"
here builds two binaries with different options for different variations
of the program. (And the build was on my old laptop - my desktop takes
half the time.)

> But I thought, should I give 'make' one more chance?

No, you did not. You thought "perhaps people really do find make
useful. I'll have to invent some more crap and mistakes to justify
refusing to use this practical tool for 40 years. Maybe if I post
enough nonsense, this time people will believe the problem is with make,
not with me".

>
> So, maybe 'make' can work under Windows,

As I said, I have used "make" with Windows for about three decades. And
I am not alone - lots of other people seem to manage fine.

>
> 'make' is only part of the problem. Yet these projects are quite
> small-scale, with dozens of source files, compared with gcc 13.2 which
> had 75,000 source files, and that was described by two people here as
> being simple to build.

I have built about a dozen gcc cross-compilers on Windows over the
years. Microcontroller manufacturers are far better about providing
"official" and supported gcc toolchain builds now, but there was a time
when you had to do more things by yourself. I've built it more recently
on Linux, because that's my main development platform. Usually you use
scripts or ready-made recipes, since you are looking for libraries,
binutils, and other tools for cross-development as well as the compiler,
but however you do it, most of the work is controlled by a few "make"
invocations.

[David Brown]

On 13/08/2023 22:45, Ben Bacarisse wrote:
> Bart <b...@freeuk.com> writes:
>

>> Lua Interpreter: This had a makefile, but gave errors.
>
> Linux software, does not compile without effort on Windows. In other
> news, bear defecates in the woods.
>
>> A closer look
>> revealed things like "-DLINUX...". I know this builds on Windows, but there
>> was no info as to how that I could see.
>
> They make it hard. It's hidden on the download page under the heading
> "Building" with the confusing link "detailed instructions".
>
> But again, what has this do with make?
>

I opened a command prompt on my Windows PC, downloaded lua source and
built it according to the "detailed instructions". All told, it took
about a minute, including reading the instructions. "make" on Windows
works fine.

[Bart]

On 14/08/2023 13:49, David Brown wrote:
> On 13/08/2023 15:53, Bart wrote:
>> OK. I'm surprised (since you say you work on embedded systems) that
>> software for those can be so elaborate.
>>
>
> I work on embedded systems - mostly microcontroller systems. But why
> would that mean few files in a project? Like most programmers, I
> organise my source files and split things up in logical sections. So
> even the smallest of programs might have 15 or more C files. And this
> particular program is not small, and includes things like a network
> stack, an RTOS, and a large number of manufacturer-supplied driver files
> in the microcontroller's SDK. The final binary is about 200 KB in size.

So several different components. Would you really need to build all the
other components when working on only one of them, if you didn't have a
makefile to tell you where each belonged?

> Oh, and I was counting compilations, not source files - the "make"
> here builds two binaries with different options for different variations
> of the program. (And the build was on my old laptop - my desktop takes
> half the time.)
>
>> But I thought, should I give 'make' one more chance?
>
> No, you did not. You thought "perhaps people really do find make
> useful. I'll have to invent some more crap and mistakes to justify
> refusing to use this practical tool for 40 years. Maybe if I post
> enough nonsense, this time people will believe the problem is with make,
> not with me".

And yet I wasn't able to successfully build a working Windows executable
for 3 out of those 4 programs (including Tcc that I added later, and
excluding the Linux-only program). Whether I was using make or not.

I *was* able to do so for LuaJIT, and using 'make'. So what was the
difference in the latter case; why didn't my 'incompetence' stretch to
that program too?

Is it possible that more care was given to making it foolproof?

Below I show how I build the Pico C project. The recommendation was to
use heavyweight MS tools to build this 0.1MB project, but it is
unnecessary given the right info.

A VS installation can be up to 100,000 times the size of pico.exe.

BTW bcc built it in 1/8th of a second, for a program half the size of
your 200KB project.

> I have built about a dozen gcc cross-compilers on Windows over the
> years. Microcontroller manufacturers are far better about providing
> "official" and supported gcc toolchain builds now, but there was a time
> when you had to do more things by yourself.

Yeah. I used to create my own languages and compilers for microcomputers
(I still do!). Plus writing all my own drivers. That's when I wasn't
also building prototypes of those computers using 120 hand-wired ICs
(that, I don't do anymore).

As for the 120,000 files of gcc 13.2 versus the 70 files of bcc: gcc-O3
runs the Pico program below about twice as fast as bcc.


--------------------
Pico C @file listing the source files needed:

clibrary.c
debug.c
expression.c
heap.c
include.c
lex.c
parse.c
picoc.c
platform.c
table.c
type.c
variable.c
ctype.c
errno.c
math.c
stdbool.c
stdio.c
stdlib.c
string.c
time.c
platform_msvc.c
library_msvc.c

Building Pico C using bcc and that 'pico' @ file:

c:\pico>bcc -old -out:pico @pico
Compiling clibrary.c to clibrary.asm
Compiling debug.c to debug.asm
Compiling expression.c to expression.asm
Compiling heap.c to heap.asm
Compiling include.c to include.asm
Compiling lex.c to lex.asm
Compiling parse.c to parse.asm
Compiling picoc.c to picoc.asm
Compiling platform.c to platform.asm
Compiling table.c to table.asm
Compiling type.c to type.asm
Compiling variable.c to variable.asm
Compiling ctype.c to ctype.asm
Compiling errno.c to errno.asm
Compiling math.c to math.asm
Compiling stdbool.c to stdbool.asm
Compiling stdio.c to stdio.asm
Compiling stdlib.c to stdlib.asm
Compiling string.c to string.asm
Compiling time.c to time.asm
Compiling platform_msvc.c to platform_msvc.asm
Compiling library_msvc.c to library_msvc.asm
Assembling to pico.exe

Building Pico C using gcc and the same file:

c:\pico>gcc -opico.exe @pico

(Some warnings not shown). Tcc failed to compile it. Options are kept
out of the @ file to keep it cross-compiler.

[Bart]

So, how did you do it? I assume this is proper Windows and not WSL.

On the downloaded source bundle from Github, there were no such
instructions.

If I go to the 'detailed instructions', there I managed to derive a list
of .c files, which I put into a text file called 'fred'.

Then I can build Lua using any of:

bcc @fred -old
tcc @fred
gcc @fred -olua -O3

So the build system is - a list of 33 files (which I compiled into one
.exe; Lua prefers to split it into .exe and .dll).

No make file needed in this case at all. The supplied makefile was 25
times bigger than the simple list.

However, the point I already made was that I /wanted/ to 'make' to see
if I could get through it without errors.

[Scott Lurndal]

David Brown <david...@hesbynett.no> writes:
>On 13/08/2023 15:53, Bart wrote:
>> Bart:
>> >> Suppose you dispensed with all that dependency stuff; how long would
>> >> it take to build such a project? Say compared with just compiling one
>> >> module.
>> >>
>>
>> David Brown:
>>
>> > That particular project takes a minute and a half to compile on my
>> > laptop (it's faster on my main machine).  It's 373 compilations, perhaps
>> > 40% of it C++.  Too long for convenience.
>>
>> OK. I'm surprised (since you say you work on embedded systems) that
>> software for those can be so elaborate.
>>
>
>I work on embedded systems - mostly microcontroller systems. But why
>would that mean few files in a project? Like most programmers, I
>organise my source files and split things up in logical sections. So
>even the smallest of programs might have 15 or more C files. And this
>particular program is not small, and includes things like a network
>stack, an RTOS, and a large number of manufacturer-supplied driver files
>in the microcontroller's SDK. The final binary is about 200 KB in size.
> Oh, and I was counting compilations, not source files - the "make"
>here builds two binaries with different options for different variations
>of the program. (And the build was on my old laptop - my desktop takes
>half the time.)

We provide the firmware for our SoCs. That firmware includes
such things as UEFI or Uboot along with all the code to isolate hardware
from the OS (e.g. ACPI and processor-specific interfaces) as well
as code to initialize the hardware and the code for the various
onboard management cores (MIPS/ARM M class). It is a very large source base.

[Scott Lurndal]

Bart <b...@freeuk.com> writes:
>On 14/08/2023 14:06, David Brown wrote:
> > On 13/08/2023 22:45, Ben Bacarisse wrote:
> >> Bart <b...@freeuk.com> writes:
> >>
> >
> >>> Lua Interpreter: This had a makefile, but gave errors.
> >>
> >> Linux software, does not compile without effort on Windows. In other
> >> news, bear defecates in the woods.
> >>
> >>> A closer look
> >>> revealed things like "-DLINUX...". I know this builds on Windows, but
> >>> there
> >>> was no info as to how that I could see.
> >>
> >> They make it hard. It's hidden on the download page under the heading
> >> "Building" with the confusing link "detailed instructions".
> >>
> >> But again, what has this do with make?
> >>
> >
> > I opened a command prompt on my Windows PC, downloaded lua source and
> > built it according to the "detailed instructions". All told, it took
> > about a minute, including reading the instructions. "make" on Windows
> > works fine.
>
>So, how did you do it? I assume this is proper Windows and not WSL.
>
>On the downloaded source bundle from Github, there were no such
>instructions.

You've been pointed to the instructions more than once in this
thread.

[Bart]

On 14/08/2023 16:49, Scott Lurndal wrote:

> Bart <b...@freeuk.com> writes:

>> So, how did you do it? I assume this is proper Windows and not WSL.
>>
>> On the downloaded source bundle from Github, there were no such
>> instructions.
>
> You've been pointed to the instructions more than once in this
> thread.

And I've twice said I've found them. I also said how I eventually
managed to build that program (hint: it didn't involve a makefile).

But what those other commentators have not said is how they would build
it or have built it. With a working Windows makefile or not? I still
don't know.

I do know that all 5 projects I mentioned could be trivially built with
the simplest script. Yet all through the other thread everybody was
pushing make and makefiles.

But then you always make these drive-past comments in claiming something
that isn't true, or suggesting I'm lying about something, or saying my
in-house languages were hobby projects, and never back them up or admit
you were wrong.

It seems like a personal campaign against me.

So, in that case: fuck you.

[David Brown]

On 14/08/2023 15:58, Bart wrote:
> On 14/08/2023 14:06, David Brown wrote:
> > On 13/08/2023 22:45, Ben Bacarisse wrote:
> >> Bart <b...@freeuk.com> writes:
> >>
> >
> >>> Lua Interpreter: This had a makefile, but gave errors.
> >>
> >> Linux software, does not compile without effort on Windows.  In other
> >> news, bear defecates in the woods.
> >>
> >>> A closer look
> >>> revealed things like "-DLINUX...". I know this builds on Windows, but
> >>> there
> >>> was no info as to how that I could see.
> >>
> >> They make it hard.  It's hidden on the download page under the heading
> >> "Building" with the confusing link "detailed instructions".
> >>
> >> But again, what has this do with make?
> >>
> >
> > I opened a command prompt on my Windows PC, downloaded lua source and
> > built it according to the "detailed instructions".  All told, it took
> > about a minute, including reading the instructions.  "make" on Windows
> > works fine.
>
> So, how did you do it? I assume this is proper Windows and not WSL.
>

Yes, "proper" Windows. I have msys2/mingw64 installed. (I haven't used
it for several years, because I haven't needed it.) I followed the
instructions - "curl" to download the lua tarball, "tar" to extract it,
then "cd" into the directory. As noted on the "detailed instructions",
I tried "make" and found it failed to guess the platform exactly. So I
then - as directed by the instructions - used "make mingw". Then I had
"lua.exe" and "luac.exe" build.

> On the downloaded source bundle from Github, there were no such
> instructions.

The "readme" file says "For complete information about Lua, visit lua.org."

Seriously, how much spoonfeeding do you need? Is it /that/ hard to read
a few lines on a webpage?

[David Brown]

On 14/08/2023 19:00, Bart wrote:
> On 14/08/2023 16:49, Scott Lurndal wrote:
>> Bart <b...@freeuk.com> writes:
>
>>> So, how did you do it? I assume this is proper Windows and not WSL.
>>>
>>> On the downloaded source bundle from Github, there were no such
>>> instructions.
>>
>> You've been pointed to the instructions more than once in this
>> thread.
>
> And I've twice said I've found them.

Apparently not.

> I also said how I eventually
> managed to build that program (hint: it didn't involve a makefile).
>
> But what those other commentators have not said is how they would build
> it or have built it.

I told you how /I/ built it on Windows - by following the instructions,
using "make" on Windows. And now in another post I've given even more
details, which I hope will answer all your questions.

> With a working Windows makefile or not? I still
> don't know.

You would have known if you'd read my post yesterday in which I said
that is /exactly/ what I did.

>
> I do know that all 5 projects I mentioned could be trivially built with
> the simplest script. Yet all through the other thread everybody was
> pushing make and makefiles.
>

Probably all projects /could/ be built with scripts - though for many
projects, it would not be trivial. But that does not make scripts the
best choice for building them. And such scripts are certainly not the
best choice when developing projects (as distinct from distributing
complete ready-to-use projects, which is a very different thing).

> But then you always make these drive-past comments in claiming something
> that isn't true, or suggesting I'm lying about something, or saying my
> in-house languages were hobby projects, and never back them up or admit
> you were wrong.
>
> It seems like a personal campaign against me.
>

When you are saying one thing, and everyone else is saying something
different, does it ever occur to you that perhaps /you/ are the one that
is in the wrong?

This is not a "campaign against you". These threads are (for me, at
least), an attempt to educate you and help you at least appreciate why
other people use tools like make and gcc, even if /you/ don't like them.
And they are also to counter misinformation and confusion that you
post - other people might read your posts and think they are accurate or
represent reality for C development.

[David Brown]

On 14/08/2023 15:39, Bart wrote:
> On 14/08/2023 13:49, David Brown wrote:
> > On 13/08/2023 15:53, Bart wrote:
> >> OK. I'm surprised (since you say you work on embedded systems) that
> >> software for those can be so elaborate.
> >>
> >
> > I work on embedded systems - mostly microcontroller systems.  But why
> > would that mean few files in a project?  Like most programmers, I
> > organise my source files and split things up in logical sections.  So
> > even the smallest of programs might have 15 or more C files.  And this
> > particular program is not small, and includes things like a network
> > stack, an RTOS, and a large number of manufacturer-supplied driver files
> > in the microcontroller's SDK.  The final binary is about 200 KB in size.
>
> So several different components. Would you really need to build all the
> other components when working on only one of them, if you didn't have a
> makefile to tell you where each belonged?
>

"make" automates the process of figuring out which compilations are
needed. Of course it doesn't do anything that I could not do manually.
And if I change "spi.c" then I know I need to re-compile that, and not
"uart.c", and other files. But that would mean that after editing
"spi.c" I'd have to manually choose to re-compile "spi.c", including the
perhaps 500 or more characters in the command line (lots of warning
flags, carefully chosen options, pre-defined macros, directory paths for
source code, object code, listing files, include paths, etc. - this is
not a "hello.c" toy on a PC). And if I changed the "clocks.h" header,
I'd have to look through dozens of source files to see which ones
included that header and needed re-compiling, and which ones do not.

Or I can type "make". (Or, more commonly, press "ctrl-B" and the IDE
will do "make" and update the source windows with markers for any issues
found.)

Which do you think is a better choice for development?


<snip the irrelevant whining about your inability to use tools everyone
else uses, and claims that your own tools are therefore better even
though they are useless to the rest of the world>

[Malcolm McLean]

The problem with that is that the make files will contain 500 or more characters
of lots of warning flags, carefully chosen options, pre-defined macros, directory
paths for source code, object code, listing files, include paths, etc). It's OK
whilst you are developing the project, because everything is set up just so.

But what happens if you need to dust it off some years later? What if something
goes wrong?

I'm not saying there's an easy answer.

But code broke for me just this morning. Someone had added a test to the test suite,
and messed with the CMake script so that it always searched for CppuTest instead
of only when tests were being built. So it broke my build, and I was in the CMake files
and git history, trying to work out what was wrong. But at least CMake gives good errors
and has intuitive syntax.

[Bart]

" but here is a simple terminal session that downloads the current
release of Lua and builds it in Linux:"

Proper Windows indeed!

> As noted on the "detailed instructions",
> I tried "make" and found it failed to guess the platform exactly. So I
> then - as directed by the instructions - used "make mingw". Then I had
> "lua.exe" and "luac.exe" build.

OK, you got me. There one mention of "mingw" (not "make mingw") on this
page:

https://www.lua.org/manual/5.4/readme.html

It is in a section called Building Lua which starts with:

"In most common UNIX-LIKE platforms, simply do "make". Here are the
details." (My emphasis)

In subsection 3, "mingw" occurs in this list, all well-known versions of
Windows:

"guess aix bsd c89 freebsd generic ios linux linux-readline
macosx mingw posix solaris"

Silly me for not spotting that and looking ahead to a section called:

"Building Lua on other systems"

Which starts with:

"If you're not using the usual Unix tools,"

Not exactly crystal clear is it.

This reminds of forums where people complaing of being caught out on
some parking infringement because the signs were not clear. And others
say of course they were clear: all the rules were explained in the small
print at the bottom of that sign placed 12' up that post, /inside/ the
car park!

Of course, even after all that, I extract a fresh copy of the
'lua-master' folders, do 'make mingw', and it says:

make: *** No rule to make target 'mingw'. Stop.

So NOW what am I doing wrong?

One thing that you must acknowledges is that those build instructions
could surely be less Unix-centric and could even have a special section
for Windows.

It is after all hardly a minor or uncommon OS. You don't really want to
scour it for clues within the 'small print'.

The only mention of Windows on that page is a suggestion to generate a
DLL instead (why?).

>> On the downloaded source bundle from Github, there were no such
>> instructions.
>
> The "readme" file says "For complete information about Lua, visit
lua.org."
>
> Seriously, how much spoonfeeding do you need? Is it /that/ hard to read
> a few lines on a webpage?

How hard is it to just say:

# For building on Windows use 'make mingw'

within the makefile? (Slightly harder is to ensure it works.)

Now I KNOW this is personal. You will not acknowledge that the build
instructions could be better; it HAS to be my fault.

NOTES

(1) Note that under Building Lua it says:

"Open a terminal window and move to the top-level directory, which is
named lua-5.4.6."

My directory isn't called lua-5.4.6. It's called "lua-master". It was
obtained from https://github.com/lua/lua using 'Download ZIP'.

If I go to Releases, then I can get one with the right name, but it's
the same set of files and still doesn't build.

(2) At the end of the day, I did after all get lua.exe, working from the
list of .o files given later on the page.

So no thanks to those earlier instructions, or to 'make'.

> Is it /that/ hard to read a few lines on a webpage?

Hand-on-heart, would you say that page was clearly written for Windows
users?

[Öö Tiib]

Then you get errors. Tools and languages change over time. Some are more
widely used and mature than others. Therefore likelihood of not finding something
that processes old makefiles is lower than not finding something that processes
say old .pro files of qmake.

> I'm not saying there's an easy answer.
>
> But code broke for me just this morning. Someone had added a test to the test suite,
> and messed with the CMake script so that it always searched for CppuTest instead
> of only when tests were being built. So it broke my build, and I was in the CMake files
> and git history, trying to work out what was wrong. But at least CMake gives good errors
> and has intuitive syntax.
>

CMake is designed to be more helpful than make indeed ... but try to sell that to
Bart then.

[Bart]

On 15/08/2023 10:00, David Brown wrote:
> On 14/08/2023 19:00, Bart wrote:
>> On 14/08/2023 16:49, Scott Lurndal wrote:
>>> Bart <b...@freeuk.com> writes:
>>
>>>> So, how did you do it? I assume this is proper Windows and not WSL.
>>>>
>>>> On the downloaded source bundle from Github, there were no such
>>>> instructions.
>>>
>>> You've been pointed to the instructions more than once in this
>>> thread.
>>
>> And I've twice said I've found them.
>
> Apparently not.
>
>> I also said how I eventually managed to build that program (hint: it
>> didn't involve a makefile).
>>
>> But what those other commentators have not said is how they would
>> build it or have built it.
>
> I told you how /I/ built it on Windows - by following the instructions,
> using "make" on Windows. And now in another post I've given even more
> details, which I hope will answer all your questions.
>
>> With a working Windows makefile or not? I still don't know.
>
> You would have known if you'd read my post yesterday in which I said
> that is /exactly/ what I did.

Your post yesterday said this:

>I opened a command prompt on my Windows PC, downloaded lua source and
built it according to the "detailed instructions". All told, it took
about a minute, including reading the instructions. "make" on Windows
works fine.

You didn't say how you invoked it. Today you said it was "make mingw".
(But you also have a funny idea of what 'proper Windows' is. For me it
is not using CYGWIN, MSYS2 or WSL.)

For me it didn't work. Please post the makefile you used; it should only
be 210 lines. If isn't 210 lines, then that can explain some things.

>> I do know that all 5 projects I mentioned could be trivially built
>> with the simplest script. Yet all through the other thread everybody
>> was pushing make and makefiles.
>>
>
> Probably all projects /could/ be built with scripts - though for many
> projects, it would not be trivial. But that does not make scripts the
> best choice for building them. And such scripts are certainly not the
> best choice when developing projects (as distinct from distributing
> complete ready-to-use projects, which is a very different thing).

I've used simple lists of source files for developing software for my
whole career.

But then, I've always taken care of everything to do with development,
and written all the software which I use at the source code level.

So I've been able to ensure the process was always usable, simple, and
fast. Even using floppies.

>> But then you always make these drive-past comments in claiming
>> something that isn't true, or suggesting I'm lying about something, or
>> saying my in-house languages were hobby projects, and never back them
>> up or admit you were wrong.
>>
>> It seems like a personal campaign against me.
>>
>
> When you are saying one thing, and everyone else is saying something
> different, does it ever occur to you that perhaps /you/ are the one that
> is in the wrong?

When I complain about people deifying C, you say but of course other
people can see its shortcomings.

But 'make' really is perfect? I find it totally and utterly unusable.
And yes I have tried to read the 240-page manual, I gave up on page 10.

And as explained, I have tried to use other people's makefiles, and
found them prone to failures. But since they are so impenetrable, I
can't fix them.

As a language designer it just offended me. That must be a better way to
do what it does, if it that is even necessary.

>
> This is not a "campaign against you". These threads are (for me, at
> least), an attempt to educate you and help you at least appreciate why
> other people use tools like make and gcc, even if /you/ don't like them.
> And they are also to counter misinformation and confusion that you
> post - other people might read your posts and think they are accurate or
> represent reality for C development.

People will read YOUR posts and get the idea that if THEY find 'make'
hard going, then it must be their fault for being too thick or not
having the right aptitude.

Since it can't possibly be because make is a terrible language.

And YES, simple solutions can work, the KISS principle.

[Öö Tiib]

You mean that page? <http://lua-users.org/wiki/BuildingLua>
IMHO it explains all ways of building it on Windows in detail. That is good
indeed as no one knows maybe our use case involves vc6 or borland c
or whatever.

You are directed there for example by <https://www.lua.org/faq.html#1.1>
And FAQ link is right on download page <https://www.lua.org/download.html>
"If you have trouble building lua read faq"

Or maybe you talk of some other page. I don't know for me the helpfulness
there is on side of impressive. Have enjoyed commercial products order
of magnitude worse supported.

[Bart]

I downloaded CMake to build Malcolm's project. I followed the
instructions and it didn't work.

So, what do you want ME to do about that? Say that it is great anyway? I
say what I see.

This project can be built trivially using:

gcc *.c freetype\*.c samplerate\*.c

So What Is The Point of using a heavyweight product like CMake? Try
selling THAT to me!

[Malcolm McLean]

Well I'm the person responsible for that failure.
Thank you very much for finding out that the instructions didn't work. I'm very close
to packaging everything up into a release, and I don't want to release it with
instructions that don't work.
As you say, at least there is a fallback. But that's not really good enough.

The point of CMake is that a lot of people will want to look at the code in an IDE.

[Bart]

From what Ben and David have said, the start point appears to be this:

https://www.lua.org/

This is the site mentioned in the makefile in the sources. Clicking on
/downloads/ as I think Ben said (remember I've already downloaded the
sources), takes you here:

https://www.lua.org/download.html

Under Building it says 'Lua is very easy to build and install'. There is
a linked called 'detailed instructions' which has been mentioned by BB
and DB, which takes you to:

https://www.lua.org/manual/5.4/readme.html

This is the page I'm referring to.

Your link does at least mention 'make mingw' directly, but also in the
context of mingw-msys; I don't know what that is. In all it is a lot
more complicated and confusing.

To build 5.4.6, from the top-level folder lua-5.4.6 which contains all
the .c and .h files, I created this file 'fred' (using 'dir/b *.c >fred,
then editing to remove the ones not needed, like luac.c), which contains:

lua.c
lapi.c
lcode.c
lctype.c
ldebug.c
ldo.c
ldump.c
lfunc.c
lgc.c
llex.c
lmem.c
lobject.c
lopcodes.c
lparser.c
lstate.c
lstring.c
ltable.c
ltm.c
lundump.c
lvm.c
lzio.c
lauxlib.c
lbaselib.c
lcorolib.c
ldblib.c
liolib.c
lmathlib.c
loadlib.c
loslib.c
lstrlib.c
ltablib.c
lutf8lib.c
linit.c

(Note: lua.c being first means no output file needed for bcc/lcc, as
they use the name of the first file.)

I then typed:

gcc -lua @fred

to get lua.exe. Now you can tweak the build using -O3 and -s for
example. Those options get you a 350KB executable.

Using 'bcc -old @fred' gets me a 340KB lua.exe. While 'tcc @fred'
creates a 370KB one.

I even started WSL, and typed this (note it needs that utterly pointless
-lm flag):

gcc -lua @fred -lm

and got lua (that is, the executable file 'lua'; an extension would be
useful!) running under Linux. So my simple script is cross-platform too!

THAT is simple. Now tell me what CMake would bring to the table.

[Bart]

My comment was a compliment not a criticism!

Yes, there was implied criticism of CMake, but it was only highlighting
that having a complex dependency brings extra ways to fail.

> As you say, at least there is a fallback. But that's not really good enough.

> The point of CMake is that a lot of people will want to look at the code in an IDE.

I'm not sure what the connection is between CMake and IDEs. Don't the
latter have a built-in way of displaying all the sources files in the
currrent and nested directories?

[Öö Tiib]

Yes, it also suggests mingw as xxx for make xxx, when plain make doesn't
cut it.

> Your link does at least mention 'make mingw' directly, but also in the
> context of mingw-msys; I don't know what that is. In all it is a lot
> more complicated and confusing.
>

The MinGW is runtime environment on Windows. Currently there
is advancement project MinGW-w64. The MSYS is collection of tools
and libraries compatible with MinGW ... it has also advancement
project MSYS2.

Nothing to do, decades old platform like Windows has accumulated
several production tool stacks over time and so there are no one-liner
answer that satisfies users of all of those.

That is interpreter. Typically people might want all of lua (the interpreter),
luac (the compiler), and liblua (the library). Lua's main appeal is that it
is embeddable script engine, and so most usual usage of it is for to make
a product scriptable.

> I then typed:
>
> gcc -lua @fred
>
> to get lua.exe. Now you can tweak the build using -O3 and -s for
> example. Those options get you a 350KB executable.
>
> Using 'bcc -old @fred' gets me a 340KB lua.exe. While 'tcc @fred'
> creates a 370KB one.
>
> I even started WSL, and typed this (note it needs that utterly pointless
> -lm flag):
>
> gcc -lua @fred -lm
>
> and got lua (that is, the executable file 'lua'; an extension would be
> useful!) running under Linux. So my simple script is cross-platform too!
>
> THAT is simple. Now tell me what CMake would bring to the table.
>

The CMake is compiler-independent. So it allows easier integration to
more varying tools and tool stacks. You might want programmers to
edit same product in both Android Studio and XCode, build the product
differently instrumented automatically on continuous integration,
deploy it to various test systems automatically, test it there automatically,
produce reports etc. Without CMake it all is of course possible but may
take too much work time of people who can do something more
interesting.

[Kenny McCormack]

In article <ubfeqj$2oop4$1...@dont-email.me>,
David Brown <david...@hesbynett.no> wrote:
...

>This is not a "campaign against you".

Of course it is.

But it is absolutely obligatory, when launching a campaign against someone,
to deny that you are doing so. So, well done. You are sticking to form.

--
"Unattended children will be given an espresso and a free kitten."

[David Brown]

I gave more details today, yes - but yesterday I had already said I used
"make".

> (But you also have a funny idea of what 'proper Windows' is. For me it
> is not using CYGWIN, MSYS2 or WSL.)

What a truly bizarre "No true Scotsman" argument! Would you also say
that it is impossible to write documents on "proper Windows" because
Windows doesn't come with a word processor?

>
> For me it didn't work. Please post the makefile you used; it should only
> be 210 lines. If isn't 210 lines, then that can explain some things.

I downloaded the tarball referenced (lua-5.4.6.tar.gz). There is a
Makefile in the main directory, of 106 lines, and a Makefile in the src
directory of 225 lines.

Did you not even /try/ to follow the instructions before complaining
that nothing worked for you?

> > When you are saying one thing, and everyone else is saying something
> > different, does it ever occur to you that perhaps /you/ are the one that
> > is in the wrong?
>
> When I complain about people deifying C, you say but of course other
> people can see its shortcomings.

No one thinks C is perfect.

>
> But 'make' really is perfect?

No one thinks "make" is perfect.

> I find it totally and utterly unusable.

That's just you. Plenty of people find it entirely usable, and
extremely useful. Other people find it hard to use, or prefer other tools.

You are not unique in disliking "make", or not finding it useful. But I
think you /are/ unique in how strongly you are convinced that you,
personally, are the only one who understands how terrible and useless
tools such as "make", "gcc", and the C language are, and how everyone
else who believes they have been using these tools for nearly 50 years
is just imagining that they work.

[Malcolm McLean]

On Tuesday, 15 August 2023 at 13:15:38 UTC+1, Bart wrote:
> On 15/08/2023 11:53, Malcolm McLean wrote:
> > On Tuesday, 15 August 2023 at 11:45:39 UTC+1, Bart wrote:
>
> >> I downloaded CMake to build Malcolm's project. I followed the
> >> instructions and it didn't work.
> >>
> >> So, what do you want ME to do about that? Say that it is great anyway? I
> >> say what I see.
> >>
> >> This project can be built trivially using:
> >>
> >> gcc *.c freetype\*.c samplerate\*.c
> >>
> >> So What Is The Point of using a heavyweight product like CMake? Try
> >> selling THAT to me!
> >>
> > Well I'm the person responsible for that failure.
> > Thank you very much for finding out that the instructions didn't work. I'm very close
> > to packaging everything up into a release, and I don't want to release it with
> > instructions that don't work.
> My comment was a compliment not a criticism!
>
> Yes, there was implied criticism of CMake, but it was only highlighting
> that having a complex dependency brings extra ways to fail.
>

Of course. So what went wrong?

> > As you say, at least there is a fallback. But that's not really good enough.
>
> > The point of CMake is that a lot of people will want to look at the code in an IDE.
> I'm not sure what the connection is between CMake and IDEs. Don't the
> latter have a built-in way of displaying all the sources files in the
> currrent and nested directories?
>

You've got to set up a project and import all the files into it. Whilst it's not hard
thing to do, it takes a minute or so, and that's enough to be barrier to someone
wanting to use the code.
Wiht CMake you type cmake -G <your IDE generator> .. and it makes an IDE for
you,
CMake has a "source group" command which groups source files and gives it a
hint what the navigation sidebar of the IDE should hold.

[David Brown]

I /do/ dust it off some years later. My record is making a change to a
customer program a few months shy of 20 years after I had last used it.
I unpacked it from my archives, on a completely different computer,
typed "make" and checked that the binary was identical to the archived
binary.

This is one of the reasons why I use make - I want /exactly/ the same
results, every time, on every machine. (Toolchains are obviously also
part of my archives.)

If you want to support multiple different compilers and versions on
different systems, that's fine too. Clearly you will not be using so
many different flags as I do, but few projects need that many. Most
people will find "-O2 -Wall" to cover many use-cases, but that's for
different kinds of development than I do.

And makefiles let you easily use variables to handle things like
different compiler paths, or common sets of flags - this is quite
normal. That means that even if you do need to make changes when moving
to a different host or different compiler, you only need to change a few
variables, not every invocation line for the compiler.

> I'm not saying there's an easy answer.

And I am not saying "make" is perfect, or will solve every potential
problem - but it can do a great deal to help.

>
> But code broke for me just this morning. Someone had added a test to the test suite,
> and messed with the CMake script so that it always searched for CppuTest instead
> of only when tests were being built. So it broke my build, and I was in the CMake files
> and git history, trying to work out what was wrong. But at least CMake gives good errors
> and has intuitive syntax.

Debugging is part of life for any tools.

[Malcolm McLean]

On Tuesday, 15 August 2023 at 14:31:08 UTC+1, David Brown wrote:
> On 15/08/2023 11:56, Malcolm McLean wrote:
>
> > But what happens if you need to dust it off some years later? What if something
> > goes wrong?
> >
> I /do/ dust it off some years later. My record is making a change to a
> customer program a few months shy of 20 years after I had last used it.
> I unpacked it from my archives, on a completely different computer,
> typed "make" and checked that the binary was identical to the archived
> binary.
>
> This is one of the reasons why I use make - I want /exactly/ the same
> results, every time, on every machine. (Toolchains are obviously also
> part of my archives.)
>

I don't want exactly the same binaries. I would hope that compilers in 20
years' time would produce slightly more efficient code than modern ones.
And of course new processors might have been developed. And whilst exactly
the same results bit for bit would be nice, it's no practical to expect it, because
of a certain amount of slop in floating point calculations.
>
But you see the wisdom of using the Baby X resource compiler instead of the
Python scripts that call external dependencies. If you want to package up
everything so it's reproducible, you can package the Baby X resource
compiler source, and, because it has no dependencies other than the standard
library, compile it.

>
> If you want to support multiple different compilers and versions on
> different systems, that's fine too. Clearly you will not be using so
> many different flags as I do, but few projects need that many. Most
> people will find "-O2 -Wall" to cover many use-cases, but that's for
> different kinds of development than I do.
>

I've discovered the clang fsanitizer flag which is great for debug builds.
But I don't need any options to get the correct results, except
CRT_SECURE_NO_WARNINGS on Windows.

>
> And makefiles let you easily use variables to handle things like
> different compiler paths, or common sets of flags - this is quite
> normal. That means that even if you do need to make changes when moving
> to a different host or different compiler, you only need to change a few
> variables, not every invocation line for the compiler.
>

The problem is that even a tiny change can mean "you've messed with it.
So any problems are no longer our responsibility. You're on your own."

>
> > I'm not saying there's an easy answer.
> And I am not saying "make" is perfect, or will solve every potential
> problem - but it can do a great deal to help.
> >
> > But code broke for me just this morning. Someone had added a test to the test suite,
> > and messed with the CMake script so that it always searched for CppuTest instead
> > of only when tests were being built. So it broke my build, and I was in the CMake files
> > and git history, trying to work out what was wrong. But at least CMake gives good errors
> > and has intuitive syntax.
> Debugging is part of life for any tools.
>

Exactly. Which is where make isn't very good and CMake is much better.

[Kaz Kylheku]

On 2023-08-15, Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> On Tuesday, 15 August 2023 at 14:31:08 UTC+1, David Brown wrote:
>> On 15/08/2023 11:56, Malcolm McLean wrote:
>>
>> > But what happens if you need to dust it off some years later? What if something
>> > goes wrong?
>> >
>> I /do/ dust it off some years later. My record is making a change to a
>> customer program a few months shy of 20 years after I had last used it.
>> I unpacked it from my archives, on a completely different computer,
>> typed "make" and checked that the binary was identical to the archived
>> binary.
>>
>> This is one of the reasons why I use make - I want /exactly/ the same
>> results, every time, on every machine. (Toolchains are obviously also
>> part of my archives.)
>>
> I don't want exactly the same binaries. I would hope that compilers in 20
> years' time would produce slightly more efficient code than modern ones.

I suspect David wants the same results when the same compiler
installation is used to compile the same code baseline.

This is called reproducibility and is a worthwhile feature of the change
management. Arguably, you don't have change management nailed down right
if you can't build again, bit for bit, something you built a week,
month or year ago.

Some GNU/Linux distros have made reproducibility a goal. So for instance
there are environment variables for freezing the build time that goes
into __DATE__ and __TIME__, and such. It's a bit involved. Everything
has to be bit exact, including generated documentation. Tools like
PDF generators that put time stamps into documents become problematic.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazi...@mstdn.ca

[Bart]

On 15/08/2023 13:53, Öö Tiib wrote:
> On Tuesday, 15 August 2023 at 14:15:03 UTC+3, Bart wrote:
>> https://www.lua.org/manual/5.4/readme.html

>> This is the page I'm referring to.
>>
> Yes, it also suggests mingw as xxx for make xxx, when plain make doesn't
> cut it.

If your read my post, it suggests that in a section whose first line
talks about Unix-like systems, with xxx in a list of mostly Unix-based
OSes, in a page where later on there is a separate section devoted to
building it on 'other systems', and which starts off saying 'if you're
not using the usual Unix tools', someone could well be forgiven for
missing it.

Especially if scanning for Windows-build information.

Of course, after I said I couldn't see it, you all minutely scrutinised
every line of it, and or maybe you started off in the Unix-specific
section out of habit, while /I/ skip it out of habit.

There is no reason to make it hard.

Why is Windows, the world's mostly popular OS and most successful OS in
the 1990s, barely mentioned? If I go into a computer shop even now and
buy a desktop PC, it will likely have Windows installed.

So there is no reason, other than churlishness, not to have a section
titled:

Building Lua on Microsoft Windows

But they'd better make sure that 'make mingw' works. The 210-line
makefile in the downloads, I'm pretty sure is not the one they have in
mind here.

If I instead download a .tgz version of Lua from here:
http://www.lua.org/ftp/, then sure enough the makefile there is 160
lines and looks at the supplied platform parameter.

But that is not the only thing: the directory structure is different
with sources in ./src, not at the top level.

The source I got from Github, either from 'Download ZIP' or the
source-code .zip from Releases, had a different structure and makefile.
Both lots are for 5.4.6.

But the .tar.gz version from Releases has the correct structure and
makefile and I believe matchs the releases from lua.org.

So the problem appears to be this:

On GitHUB, the .zip and .tar.gz versions differ in their contents. The
folder structure is different, and the makefile is different.

Oddly, the .zip version, usually associated with Windows, has a makefile
that doesn't build under Windows, and if I try it under Linux, fails to
link symbols because of that are part of WinAPI.

So, there appears to be an actual problem with that Github repository.

But I bet I'm not going to get any apologies: I'm still just a bumbling,
incompetent idiot.

I'm also the idiot that highlighted clarity issues in the Readme file,
and discovered a discrepancy in the .zip and .tar.gz versions.

The Github directory displayed, and the makefile, are also incorrect as
they correspond to the ZIP versions.

>> Your link does at least mention 'make mingw' directly, but also in the
>> context of mingw-msys; I don't know what that is. In all it is a lot
>> more complicated and confusing.
>>
> The MinGW is runtime environment on Windows. Currently there
> is advancement project MinGW-w64. The MSYS is collection of tools
> and libraries compatible with MinGW ... it has also advancement
> project MSYS2.

I have mingw which I believe refers to implementations of gcc on Windows.

MSYS is a separate product.

>
> Nothing to do, decades old platform like Windows has accumulated
> several production tool stacks over time and so there are no one-liner
> answer that satisfies users of all of those.

There is always plain Windows. CYGWIN, MSYS2 and WSL are just extra
layers. Ones that are necessary for a project as simple as this.

[David Brown]

On 15/08/2023 15:58, Malcolm McLean wrote:
> On Tuesday, 15 August 2023 at 14:31:08 UTC+1, David Brown wrote:
>> On 15/08/2023 11:56, Malcolm McLean wrote:
>>
>>> But what happens if you need to dust it off some years later? What if something
>>> goes wrong?
>>>
>> I /do/ dust it off some years later. My record is making a change to a
>> customer program a few months shy of 20 years after I had last used it.
>> I unpacked it from my archives, on a completely different computer,
>> typed "make" and checked that the binary was identical to the archived
>> binary.
>>
>> This is one of the reasons why I use make - I want /exactly/ the same
>> results, every time, on every machine. (Toolchains are obviously also
>> part of my archives.)
>>
> I don't want exactly the same binaries. I would hope that compilers in 20
> years' time would produce slightly more efficient code than modern ones.

That's fine for many uses. For embedded systems, and other situations
where you want high reliability and repeatability, you want repeatable
builds. (It's become increasingly of interest in the Linux world too -
Debian, for example, has an ongoing project to make its entire source
base support repeatable builds.)

I generally aim for the most modern practical toolchain for new
projects, but once a project is solidly established and real versions
are delivered to the customer, I won't change toolchains without very
good reason. The possibility of introducing new bugs or issues is
unacceptable - long term testing is of a binary, not of source code.

> And of course new processors might have been developed. And whilst exactly
> the same results bit for bit would be nice, it's no practical to expect it, because
> of a certain amount of slop in floating point calculations.

I am not talking about the output of sloppy programs - I am talking
about the compiled binary image (striped of debug information and that
kind of thing, of course). I don't see why variable floating point
calculations would affect the result of a compilation or link.

And floating point, done to IEEE standards, should also be repeatable.

I would therefore expect something like an mp3 decoder used in a
resource compiler as part of a build, to give identical results every
time, even on different hardware, even if using floating point.
Obviously the particular version of the mp3 decoder would also have to
be considered as part of the toolchain and archived accordingly.

>>
> But you see the wisdom of using the Baby X resource compiler instead of the
> Python scripts that call external dependencies. If you want to package up
> everything so it's reproducible, you can package the Baby X resource
> compiler source, and, because it has no dependencies other than the standard
> library, compile it.

That could be an advantage in some cases, yes. It would not be in my
own use-cases, as the generated could would not be affected by the
version of Python or its libraries, but I certainly agree that while it
is easier to archive a Python script than your Baby X resource compiler,
it is easier to archive your resource compiler than a Python installation.

>>
>> If you want to support multiple different compilers and versions on
>> different systems, that's fine too. Clearly you will not be using so
>> many different flags as I do, but few projects need that many. Most
>> people will find "-O2 -Wall" to cover many use-cases, but that's for
>> different kinds of development than I do.
>>
> I've discovered the clang fsanitizer flag which is great for debug builds.
> But I don't need any options to get the correct results, except
> CRT_SECURE_NO_WARNINGS on Windows.

"Correct" can mean many things. For embedded systems, "runs as fast as
required" can be part of "correct", as can be "as compact as needed".
But also there are many flags to select details of devices in use -
microcontrollers are not as generic as PC's.

>>
>> And makefiles let you easily use variables to handle things like
>> different compiler paths, or common sets of flags - this is quite
>> normal. That means that even if you do need to make changes when moving
>> to a different host or different compiler, you only need to change a few
>> variables, not every invocation line for the compiler.
>>
> The problem is that even a tiny change can mean "you've messed with it.
> So any problems are no longer our responsibility. You're on your own."

That is not a problem unless you mess with it.

But our company supports its customers - we do not say "you're on your
own", as a general rule.

>>
>>> I'm not saying there's an easy answer.
>> And I am not saying "make" is perfect, or will solve every potential
>> problem - but it can do a great deal to help.
>>>
>>> But code broke for me just this morning. Someone had added a test to the test suite,
>>> and messed with the CMake script so that it always searched for CppuTest instead
>>> of only when tests were being built. So it broke my build, and I was in the CMake files
>>> and git history, trying to work out what was wrong. But at least CMake gives good errors
>>> and has intuitive syntax.
>> Debugging is part of life for any tools.
>>
> Exactly. Which is where make isn't very good and CMake is much better.
>

That may be true - "make" can be difficult to debug. But you learn the
tricks there too, and there are always ways to debug it.

[Bart]

On 15/08/2023 14:21, David Brown wrote:
> On 15/08/2023 12:40, Bart wrote:
>> (But you also have a funny idea of what 'proper Windows' is. For me it
>> is not using CYGWIN, MSYS2 or WSL.)
>
> What a truly bizarre "No true Scotsman" argument! Would you also say
> that it is impossible to write documents on "proper Windows" because
> Windows doesn't come with a word processor?

What is bizarre is thinking WSL (ie. Ubuntu) is proper Windows. I can't
build under WSL and send the binary to somebody running Windows. Not
unless they also run it under their Ubuntu.

So why even bother with Windows?

MSYS2, I've no idea what I'll end up with there. Either way, none of
these extra layers is necessary.

Compiling C under pure Windows is not hard!

>>
>> For me it didn't work. Please post the makefile you used; it should
>> only be 210 lines. If isn't 210 lines, then that can explain some
things.
>
> I downloaded the tarball referenced (lua-5.4.6.tar.gz). There is a
> Makefile in the main directory, of 106 lines, and a Makefile in the src
> directory of 225 lines.
>
> Did you not even /try/ to follow the instructions before complaining
> that nothing worked for you?

My recent post goes into this in more detail. But, I've believe the ZIP
files from the Github Lua repository are incorrect. This applies to:

* The displayed file hierarchy

* The ZIP from Download ZIP

* The ZIPs (the latest at least) from Releases.

They don't match the contents of the .tar.gz versions. I think this the
first directory layer is missing, so it only has the inner makefile, not
the outer makefile of 106 lines.

I tried building only via those ZIPs.

So, whose fault is that?

I usually avoid .tar.gz files since they are a pig to extract on
Windows. It involves using 7-Zip, but is still a trial-and-error process.

[Scott Lurndal]

Bart <b...@freeuk.com> writes:

>So why even bother with Windows?

A good question, indeed.

[MJ OS_EXAMINE]

On Tuesday, August 15, 2023 at 11:12:10 AM UTC-4, Bart wrote:
> I usually avoid .tar.gz files since they are a pig to extract on
> Windows. It involves using 7-Zip, but is still a trial-and-error process.

I don't think that's been necessary for a few Windows versions now.
These days, Windows comes with its own built-in tar that allows you to just:
tar -xvf lua-5.4.6.tar.gz
x lua-5.4.6/
x lua-5.4.6/Makefile
x lua-5.4.6/doc/
x lua-5.4.6/doc/luac.1
x lua-5.4.6/doc/manual.html
x lua-5.4.6/doc/manual.css
x lua-5.4.6/doc/contents.html
x lua-5.4.6/doc/lua.css
x lua-5.4.6/doc/osi-certified-72x60.png
x lua-5.4.6/doc/logo.gif
x lua-5.4.6/doc/lua.1
x lua-5.4.6/doc/index.css
x lua-5.4.6/doc/readme.html
x lua-5.4.6/src/
x lua-5.4.6/src/ldblib.c
x lua-5.4.6/src/lmathlib.c
x lua-5.4.6/src/loslib.c
x lua-5.4.6/src/lvm.c
x lua-5.4.6/src/ldo.h
x lua-5.4.6/src/lua.h
x lua-5.4.6/src/lgc.h
x lua-5.4.6/src/ltm.h
x lua-5.4.6/src/loadlib.c
x lua-5.4.6/src/lmem.c
x lua-5.4.6/src/lstate.h
x lua-5.4.6/src/Makefile
x lua-5.4.6/src/lzio.h
x lua-5.4.6/src/luaconf.h
x lua-5.4.6/src/lopcodes.c
x lua-5.4.6/src/lua.c
x lua-5.4.6/src/lundump.h
x lua-5.4.6/src/ljumptab.h
x lua-5.4.6/src/lbaselib.c
x lua-5.4.6/src/ltable.c
x lua-5.4.6/src/ldump.c
x lua-5.4.6/src/liolib.c
x lua-5.4.6/src/llimits.h
x lua-5.4.6/src/lfunc.h
x lua-5.4.6/src/lualib.h
x lua-5.4.6/src/lzio.c
x lua-5.4.6/src/lopnames.h
x lua-5.4.6/src/lctype.c
x lua-5.4.6/src/lmem.h
x lua-5.4.6/src/llex.h
x lua-5.4.6/src/ltable.h
x lua-5.4.6/src/lstring.c
x lua-5.4.6/src/ldebug.h
x lua-5.4.6/src/lprefix.h
x lua-5.4.6/src/llex.c
x lua-5.4.6/src/linit.c
x lua-5.4.6/src/lobject.h
x lua-5.4.6/src/lapi.h
x lua-5.4.6/src/ldebug.c
x lua-5.4.6/src/ldo.c
x lua-5.4.6/src/lvm.h
x lua-5.4.6/src/lauxlib.c
x lua-5.4.6/src/luac.c
x lua-5.4.6/src/lctype.h
x lua-5.4.6/src/lstring.h
x lua-5.4.6/src/lcorolib.c
x lua-5.4.6/src/lutf8lib.c
x lua-5.4.6/src/lgc.c
x lua-5.4.6/src/lstate.c
x lua-5.4.6/src/lundump.c
x lua-5.4.6/src/ltablib.c
x lua-5.4.6/src/lauxlib.h
x lua-5.4.6/src/ltm.c
x lua-5.4.6/src/lparser.c
x lua-5.4.6/src/lcode.h
x lua-5.4.6/src/lobject.c
x lua-5.4.6/src/lcode.c
x lua-5.4.6/src/lopcodes.h
x lua-5.4.6/src/lfunc.c
x lua-5.4.6/src/lapi.c
x lua-5.4.6/src/lparser.h
x lua-5.4.6/src/lua.hpp
x lua-5.4.6/src/lstrlib.c
x lua-5.4.6/README

See:
https://learn.microsoft.com/en-us/virtualization/community/team-blog/2017/20171219-tar-and-curl-come-to-windows

[David Brown]

On 15/08/2023 17:11, Bart wrote:
> On 15/08/2023 14:21, David Brown wrote:
> > On 15/08/2023 12:40, Bart wrote:
> >> (But you also have a funny idea of what 'proper Windows' is. For me it
> >> is not using CYGWIN, MSYS2 or WSL.)
> >
> > What a truly bizarre "No true Scotsman" argument!  Would you also say
> > that it is impossible to write documents on "proper Windows" because
> > Windows doesn't come with a word processor?
>
> What is bizarre is thinking WSL (ie. Ubuntu) is proper Windows. I can't
> build under WSL and send the binary to somebody running Windows. Not
> unless they also run it under their Ubuntu.
>
> So why even bother with Windows?
>
> MSYS2, I've no idea what I'll end up with there.

Right, so you'll condemn it from the get-go despite having no idea about
it? That's a great attitude.

> Either way, none of
> these extra layers is necessary.

Apparently they are. Certainly I had no problems and built Lua in under
a minute (including downloading and reading the instructions), resulting
in an executable that will work on any Windows system. You, who do not
have msys2 or anything else that even hints of coming from the *nix
world, have had all sorts of trouble.

>
> Compiling C under pure Windows is not hard!
>
>
> >>
> >> For me it didn't work. Please post the makefile you used; it should
> >> only be 210 lines. If isn't 210 lines, then that can explain some
> things.
> >
> > I downloaded the tarball referenced (lua-5.4.6.tar.gz).  There is a
> > Makefile in the main directory, of 106 lines, and a Makefile in the src
> > directory of 225 lines.
> >
> > Did you not even /try/ to follow the instructions before complaining
> > that nothing worked for you?
>
> My recent post goes into this in more detail. But, I've believe the ZIP
> files from the Github Lua repository are incorrect. This applies to:
>
> * The displayed file hierarchy
>
> * The ZIP from Download ZIP
>
> * The ZIPs (the latest at least) from Releases.
>

The build instructions and the releases are from lua.org, not github.
That's for development work (which is most likely targeting Linux).

> They don't match the contents of the .tar.gz versions. I think this the
> first directory layer is missing, so it only has the inner makefile, not
> the outer makefile of 106 lines.
>
> I tried building only via those ZIPs.
>
> So, whose fault is that?

Yours - you did not read the build instructions, but ploughed on with
your own guesswork and got into trouble.

>
> I usually avoid .tar.gz files since they are a pig to extract on
> Windows. It involves using 7-Zip, but is still a trial-and-error process.
>

Is there /nothing/ in this world that you don't find hard? How can you
possibly have trouble with a simple compressed archive? It's not as if
it contains filenames that Windows can't handle.

[Öö Tiib]

On Tuesday, 15 August 2023 at 17:57:24 UTC+3, Bart wrote:
> On 15/08/2023 13:53, Öö Tiib wrote:
> > On Tuesday, 15 August 2023 at 14:15:03 UTC+3, Bart wrote:
> >> https://www.lua.org/manual/5.4/readme.html
>
> >> This is the page I'm referring to.
> >>
> > Yes, it also suggests mingw as xxx for make xxx, when plain make doesn't
> > cut it.
> If your read my post, it suggests that in a section whose first line
> talks about Unix-like systems, with xxx in a list of mostly Unix-based
> OSes, in a page where later on there is a separate section devoted to
> building it on 'other systems', and which starts off saying 'if you're
> not using the usual Unix tools', someone could well be forgiven for
> missing it.
>
> Especially if scanning for Windows-build information.
>
> Of course, after I said I couldn't see it, you all minutely scrutinised
> every line of it, and or maybe you started off in the Unix-specific
> section out of habit, while /I/ skip it out of habit.
>

I did not, like I said, I did check what is so bad about it on Windows
(having nothing but a MacBook anyway at the moment) and was
on <http://lua-users.org/wiki/BuildingLua> that looked like
good page (to me) with majority of information being how to build
it on Windows.

Why anyone has to apologise? Lua is free and open source, provided in
fair hope that it helps, not in hope that it confuses. If it confused you
then that likely happened because everyone have different experiences,
needs and expectations. Similarly someone expecting something like
JavaScript, Python or Ruby from Lua might be confused ... but so it
went.

> >> Your link does at least mention 'make mingw' directly, but also in the
> >> context of mingw-msys; I don't know what that is. In all it is a lot
> >> more complicated and confusing.
> >>
> > The MinGW is runtime environment on Windows. Currently there
> > is advancement project MinGW-w64. The MSYS is collection of tools
> > and libraries compatible with MinGW ... it has also advancement
> > project MSYS2.
> I have mingw which I believe refers to implementations of gcc on Windows.
>
> MSYS is a separate product.
>

Yes, I said nothing contradicting with it, it is made to help with installation
and usage of various open source programming tools and libraries. If it does
not help you then do not use. But also do not demonise groundlessly.

> >
> > Nothing to do, decades old platform like Windows has accumulated
> > several production tool stacks over time and so there are no one-liner
> > answer that satisfies users of all of those.
>
> There is always plain Windows. CYGWIN, MSYS2 and WSL are just extra
> layers. Ones that are necessary for a project as simple as this.
>

A plain Windows comes without software development tools whatsoever.
That is because vast majority of its users are not software developers.
So one obviously needs to install something for to write programs on
it.

[Kenny McCormack]

In article <1dcd9ed8-d345-45f1...@googlegroups.com>,
MJ OS_EXAMINE <m650...@gmail.com> wrote:

>On Tuesday, August 15, 2023 at 11:12:10AM UTC-4, Bart wrote:
>> I usually avoid .tar.gz files since they are a pig to extract on
>> Windows. It involves using 7-Zip, but is still a trial-and-error process.
>
>I don't think that's been necessary for a few Windows versions now.
>These days, Windows comes with its own built-in tar that allows you to just:

Yes, but "modern" Windows is crap.

Last good version: XP
Last usable version: 7

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/DanQuayle

[Scott Lurndal]

IIRC, Windows filesystems are case insensitive. Would not that preclude
successfully unpacking a tarball which contains two filenames which differ
only in case?

[Kenny McCormack]

In article <qbOCM.632529$TPw2....@fx17.iad>,

Yes, true, but irrelevant.

I believe David is asserting that the lua tarball (which *is* the thing we
are discussing) does not have any such issues.

Whether that is actually true or not, I have no idea. Nor do I care.

--
Politics is show business for ugly people.

Sports is politics for stupid people.

[Bart]

On 15/08/2023 17:03, David Brown wrote:

> On 15/08/2023 17:11, Bart wrote:
>> My recent post goes into this in more detail. But, I've believe the
>> ZIP files from the Github Lua repository are incorrect. This applies to:
>>
>> * The displayed file hierarchy
>>
>> * The ZIP from Download ZIP
>>
>> * The ZIPs (the latest at least) from Releases.
>>
>
> The build instructions and the releases are from lua.org, not github.
> That's for development work (which is most likely targeting Linux).
>
>> They don't match the contents of the .tar.gz versions. I think this
>> the first directory layer is missing, so it only has the inner
>> makefile, not the outer makefile of 106 lines.
>>
>> I tried building only via those ZIPs.
>>
>> So, whose fault is that?
>
> Yours - you did not read the build instructions, but ploughed on with
> your own guesswork and got into trouble.

The releases page for Github Lua, for version 5.4.6, has these two assets:

* Source code: v5.4.6.zip

* Source code: v5.4.6.tar.gz

TELL me where in the build instructions it says that the contents of
these two files are incompatible.

THEN then tell me why they are incompatible, and what the point is of
the .zip version since it has a missing outer makefile.

NOW tell me why on earth someone would know, or even guess, that the
source bundles contained in those files are anything other than the same
data, packaged in different types of containers.

This is from a Github page about downloading source code archives:

"(4) To download the source code, click Source code (zip) or Source
code (tar.gz)."

(https://docs.github.com/en/repositories/working-with-files/using-files/downloading-source-code-archives)

Notice it says 'zip' OR 'tar.gz'. Presumably it shouldn't matter which.

------------------------------------------------

You know, one thing is going 100% certain in this thread: you are never
for one minute going to admit that I'm right in there being something
wrong with those Github ZIPs.

You didn't see the problem because you either obtained the source bundle
elsewhere, or would have used only the .tar.gz version.

So, fuck you as well as Scott. This clearly is a personal vendetta.

You hate me so much that whenever I find a problem anywhere, it
automatically has to be my fault, even when it isn't!

And you're so intent on proving me wrong, that you even delude yourself
that doing this:

curl -R -O http://www.lua.org/ftp/lua-5.4.6.tar.gz
tar zxf lua-5.4.6.tar.gz
cd lua-5.4.6
make all test

is 'installing it on Windows'. And when challenged, you say that doing
it under MSYS2 is also 'installing it on Windows'.

You know, I don't believe you actually know how to do this under plain
Windows! Otherwise you would have done so; you must know that's what I use.)

This is what /I/ achieved in trying to build this project:

* I managed it without make

* I managed it in plain Windows

* I managed it even from the faulty Github ZIP files with the missing
outer layer

* I /discovered/ there was a missing outer layer (you're welcome)

* I found out the lua.org's Readme should be overhauled as the Windows
build info is unclear (you of course couldn't give a cuss about that, so
long as you can prove me wrong about the info being in there, if you
joined enough dots)

So, what have /you/ achieved?

[Bart]

On 15/08/2023 16:58, MJ OS_EXAMINE wrote:
> On Tuesday, August 15, 2023 at 11:12:10 AM UTC-4, Bart wrote:
>> I usually avoid .tar.gz files since they are a pig to extract on
>> Windows. It involves using 7-Zip, but is still a trial-and-error
process.
>
> I don't think that's been necessary for a few Windows versions now.
> These days, Windows comes with its own built-in tar that allows you
to just:
> tar -xvf lua-5.4.6.tar.gz

> See:
>
https://learn.microsoft.com/en-us/virtualization/community/team-blog/2017/20171219-tar-and-curl-come-to-windows

Oh is it back? I remember 'tar' from long ago, but it only did .tar
files iirc.

But your link is dated 2023, it seems to be recent.

.tar.gz and like files I think were supposed to be handled directly by
Windows, but that never worked. I had to use a package called 7-Zip, and
it was dire.

You clicked Extract, and it did half the job; you had a .tar file. You
clicked extract on that, and nothing happened. Eventually it would deign
to extract files, but it was pot-luck where they would end up, or how
deeply nested, even if you gave a path.

It was confusing also because you could just click and go inside the
archive, but I think you'd need to be at the right location for Extract
to work.

So thanks.

[Thiago Adams]

On Sunday, August 13, 2023 at 10:53:59 AM UTC-3, Bart wrote:
> Bart:
> >> Suppose you dispensed with all that dependency stuff; how long would
> >> it take to build such a project? Say compared with just compiling one
> >> module.

I am still using and very satisfied with the solution we already had topics here that
is create a simple executable that does the build.

All I need for windows

cl build.c && build

All I need for Linux
gcc build.c -o build && ./build


When you have several files to be compiled, having one more file that is the build
itself does not make any difference. Usage of preprocessor is very handy.

I also have automatic unit tests . all I need to do is

cl -DTEST build.c && build

[Keith Thompson]

Bart <b...@freeuk.com> writes:
[...]

> My recent post goes into this in more detail. But, I've believe the
> ZIP files from the Github Lua repository are incorrect.

You're right.

The GitHub repo for Lua is
https://github.com/lua/lua
It includes (not as part of the repo itself) a number of releases,
including:
https://github.com/lua/lua/archive/refs/tags/v5.4.6.zip
https://github.com/lua/lua/archive/refs/tags/v5.4.6.tar.gz

The lua.org site provides a tarball:
https://www.lua.org/ftp/lua-5.4.6.tar.gz
I don't see any zip files on lua.org.

The zipfile and tarball from the GitHub release match each other, but do
not match the tarball from lua.org.

> So, whose fault is that?

I have no idea, but I hardly think comp.lang.c is the place to complain
about it.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[Keith Thompson]

Bart <b...@freeuk.com> writes:
[...]

> The releases page for Github Lua, for version 5.4.6, has these two assets:
>
> * Source code: v5.4.6.zip
>
> * Source code: v5.4.6.tar.gz
>
> TELL me where in the build instructions it says that the contents of
> these two files are incompatible.

It doesn't, because their contents are identical. I just checked.

They differ from the lua-5.4.6.tar.gz file on the lua.org website.

https://github.com/lua/lua/archive/refs/tags/v5.4.6.zip
https://github.com/lua/lua/archive/refs/tags/v5.4.6.tar.gz
https://www.lua.org/ftp/lua-5.4.6.tar.gz

The release files on github.com are copies of the git repo. The
lua-5.4.6.tar.gz was *generated* from the files in the git repo.
It's created by the Lua maintainers; I don't know how.

The tarball on the lua.org web site is the one you should use to build
Lua from source. (If you want to work on developing Lua itself, you
should clone the repo. I'm not convinced that the GitHub release files
are particularly useful.)

> THEN then tell me why they are incompatible, and what the point is of
> the .zip version since it has a missing outer makefile.
>
> NOW tell me why on earth someone would know, or even guess, that the
> source bundles contained in those files are anything other than the
> same data, packaged in different types of containers.

That's exactly what they are, but they differ from the tar.gz file from
lua.org.

People who want to build Lua from source (without necessarily wanting to
work on the Lua implementation) should build from the .tar.gz file from
lua.org.

[...]

> You know, one thing is going 100% certain in this thread: you are
> never for one minute going to admit that I'm right in there being
> something wrong with those Github ZIPs.
>
> You didn't see the problem because you either obtained the source
> bundle elsewhere, or would have used only the .tar.gz version.
>
> So, fuck you as well as Scott. This clearly is a personal vendetta.

Dude, calm down. Scott likely wasn't aware of the GitHub release files.
The presence of those files is genuinely confusing, but that's not
Scott's fault.

[Phil Carmody]

Depends on whether "successfully" is viewed from the perspective of
the person trying to root your system, as in this git(hub) bug from
nearly a decade ago:
https://www.beyondtrust.com/blog/entry/dissecting-githubs-case-insensitive-discrepancies
TL;DF: create some ``.Git/hooks/*'' files or a ``.Git/config'' file

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

[Bart]

On 15/08/2023 20:48, Keith Thompson wrote:
> Bart <b...@freeuk.com> writes:
> [...]
>> My recent post goes into this in more detail. But, I've believe the
>> ZIP files from the Github Lua repository are incorrect.
>
> You're right.
>
> The GitHub repo for Lua is
> https://github.com/lua/lua
> It includes (not as part of the repo itself) a number of releases,
> including:
> https://github.com/lua/lua/archive/refs/tags/v5.4.6.zip
> https://github.com/lua/lua/archive/refs/tags/v5.4.6.tar.gz
>
> The lua.org site provides a tarball:
> https://www.lua.org/ftp/lua-5.4.6.tar.gz
> I don't see any zip files on lua.org.
>
> The zipfile and tarball from the GitHub release match each other, but do
> not match the tarball from lua.org.

OK, that one was my mistake then. But it means they're both wrong. And
if that Mr. DB had downloaded the source code from the Github, then the
make instructions he saw on lua.org would not have worked because of a
missing makefile.

>> So, whose fault is that?
>
> I have no idea, but I hardly think comp.lang.c is the place to complain
> about it.

What I'm complaining about is being falsely (and I believe maliciously)
accused of incompetence:

BC:

>> So, whose fault is that?
>

DB:

> Yours - you did not read the build instructions, but ploughed on with
> your own guesswork and got into trouble.

That doesn't bother you I guess. Although this won't stop DB, who will
claim that of course I should have known that different kinds of source
'tarballs' exist for the version of product, and only some of them will
work with the given build instructions.

Although I did mention Github regarding Lua two days ago; you'd think
someone would have told me that was the wrong site to download source
code from, if it's so bleeding obvious.

As for who is at fault; I'd suggest:

(1) The github site for not mentioning anything about it at all, like:
'download the proper tarball from lua.org' if you want to build it. (Why
isn't that top layer present anyway?)

(2) Even with the correct sources, you'd have to go on a scavenger hunt
through lua.org's Readme page to find the right instructions to run
'make' for plain Windows.


BTW the thread is about build systems. My contention was that 'make' on
Windows (actual Windows not Linux running under Windows) is generally
troublesome.

I haven't seen evidence to the contrary.

[Bart]

On 15/08/2023 21:36, Bart wrote:


> As for who is at fault; I'd suggest:
>
> (1) The github site for not mentioning anything about it at all, like:
> 'download the proper tarball from lua.org' if you want to build it. (Why
> isn't that top layer present anyway?)
>
> (2) Even with the correct sources, you'd have to go on a scavenger hunt
> through lua.org's Readme page to find the right instructions to run
> 'make' for plain Windows.

BTW, why does Github (on this project and I've seen it on others)
provide both .zip and .tar.gz sources?

According to DB, processing .tar.gz files is so utterly trivial that
there appears to be little point to using .zip.

People who prefer .zip will of course choose that if both are options.

[Vir Campestris]

On 15/08/2023 10:08, David Brown wrote:
> "make" automates the process of figuring out which compilations are
> needed.  Of course it doesn't do anything that I could not do manually.
> And if I change "spi.c" then I know I need to re-compile that, and not
> "uart.c", and other files.  But that would mean that after editing
> "spi.c" I'd have to manually choose to re-compile "spi.c", including the
> perhaps 500 or more characters in the command line (lots of warning
> flags, carefully chosen options, pre-defined macros, directory paths for
> source code, object code, listing files, include paths, etc. - this is
> not a "hello.c" toy on a PC).  And if I changed the "clocks.h" header,
> I'd have to look through dozens of source files to see which ones
> included that header and needed re-compiling, and which ones do not.
>
> Or I can type "make".  (Or, more commonly, press "ctrl-B" and the IDE
> will do "make" and update the source windows with markers for any issues
> found.)
>
> Which do you think is a better choice for development?

When I was still being paid to do this stuff (and not just following the
group out of nostalgia) we used a tool called Ice Cream

<https://github.com/icecc/icecream>

which distributed the work around the pool of machines in the office.
OK, there was a _lot_ of C++ in it, but a clean compile still took an
hour or so. If you are finding that your compiles take a long time it's
worth looking into.

That page mentions distcc as one of the ancestors.

Andy

[David Brown]

Yes - but the tarball in question does not have such files.

(NTFS supports having files whose names differ only in case, because it
was made to support POSIX semantics, from early plans for WinNT to be
more POSIX-like. It is possible to create filenames on an NTFS drive
that normal Windows programs can't handle, causing much fun as a prank.)

[Keith Thompson]

You're far too quick to assume malice.

> BC:
>>> So, whose fault is that?
>>
> DB:
>> Yours - you did not read the build instructions, but ploughed on with
>> your own guesswork and got into trouble.

I won't attempt to speak for DB, but I doubt that it occurred to him
that the release files on GitHub differ so substantially from the
.tar.gz files on lua.org.

> That doesn't bother you I guess. Although this won't stop DB, who will
> claim that of course I should have known that different kinds of
> source 'tarballs' exist for the version of product, and only some of
> them will work with the given build instructions.
>
> Although I did mention Github regarding Lua two days ago; you'd think
> someone would have told me that was the wrong site to download source
> code from, if it's so bleeding obvious.

It's not obvious, and nobody has said that it is. I would have assumed
that the release .tar.gz file from GitHub was similar to the .tar.gz
file from lua.org until I checked.

> As for who is at fault; I'd suggest:
>
> (1) The github site for not mentioning anything about it at all, like:
> 'download the proper tarball from lua.org' if you want to build
> it. (Why isn't that top layer present anyway?)

GitHub release files are just packaged copies of the files in the repo.
The release tarball from lua.org is built from that. For example, the
GitHub repo includes documentation in what appears to be a
project-specific format; the lua.org release includes generated man
pages and html files.

The README.md file says: "Download official Lua releases from Lua.org.".

Yes, the presence of the "release" files on GitHub is misleading. Now
that we've established that, can we stop complaining about it here?

[...]

[David Brown]

On 15/08/2023 19:49, Bart wrote:

> You know, one thing is going 100% certain in this thread: you are never
> for one minute going to admit that I'm right in there being something
> wrong with those Github ZIPs.
>
> You didn't see the problem because you either obtained the source bundle
> elsewhere, or would have used only the .tar.gz version.
>

Look, I have no idea if these are the same or different. I don't know,
and don't care. The only reason I was at the lua website at all was
because /you/ picked it as something that "proves" that make never works
on Windows. I went to the lua website, followed the instructions on how
to build lua on Windows, and it worked - using "make". /You/ did not
not follow the instructions, and you got in trouble. No doubt you'd
have got in trouble even if you did follow the instructions, because you
are always so determined to have everything fail.

I am not going to look at the zip files, or compare them, and I am
certainly not going to spend any more effort trying to help you figure
out what you did wrong.

> You hate me so much that whenever I find a problem anywhere, it
> automatically has to be my fault, even when it isn't!

I don't hate you at all - if I did, then I would not have been wasting
so much time trying to help you.

>
> And you're so intent on proving me wrong, that you even delude yourself
> that doing this:
>
>    curl -R -O http://www.lua.org/ftp/lua-5.4.6.tar.gz
>    tar zxf lua-5.4.6.tar.gz
>    cd lua-5.4.6
>    make all test
>
> is 'installing it on Windows'.

It /is/ installing it on Windows.

> And when challenged, you say that doing
> it under MSYS2 is also 'installing it on Windows'.

I have msys2 installed. On Windows. I used tools from that (including
make) to build Lua. On Windows. It resulted in Windows exe files for
Lua. They are on my Windows machine. I can now run lua on Windows.
(This is Windows 7, with no WSL in sight, no virtual machines, or
anything like that.) I can copy these exe files to another windows
machine, and they work there too. How is that /not/ "installing it on
windows" ? What is your criteria here - if it works for someone else,
then they must naturally have been cheating in some way, because it
could not possibly be that /you/ have the problem?

>
> You know, I don't believe you actually know how to do this under plain
> Windows! Otherwise you would have done so; you must know that's what I
> use.)
>

By /my/ ruling, any system with "bcc" or "tcc" is not plain Windows.
Therefore you failed.

Does that sound familiar? Any more goalposts you want to shuffle around
and move to completely different pitches in another feeble attempt to
look less pathetic?

>
> So, what have /you/ achieved?
>

I did exactly what you claimed was impossible - used "make" to build Lua
on windows.

[Bart]

On 15/08/2023 22:09, David Brown wrote:
> On 15/08/2023 19:49, Bart wrote:
>
>> You know, one thing is going 100% certain in this thread: you are
>> never for one minute going to admit that I'm right in there being
>> something wrong with those Github ZIPs.
>>
>> You didn't see the problem because you either obtained the source
>> bundle elsewhere, or would have used only the .tar.gz version.
>>
>
> Look, I have no idea if these are the same or different. I don't know,
> and don't care. The only reason I was at the lua website at all was
> because /you/ picked it as something that "proves" that make never works
> on Windows. I went to the lua website, followed the instructions on how
> to build lua on Windows, and it worked - using "make". /You/ did not
> not follow the instructions,

I downloaded an open source project like I've done a hundred others:
from Github. It's usually expected to have everything needed to build
the project, except for the actual tools.

> and you got in trouble. No doubt you'd
> have got in trouble even if you did follow the instructions, because you
> are always so determined to have everything fail.

You don't see the failures because most open source software is
developed for Unix-like OSes, so build systems are well-tested because
so many will be using that and will have reported failures.

In addition, even for software that runs on Windows, you hide behind a
wall of Linux utilities; using MSYS2 or WSL.

So really, it's not surprising that everything works for you with hardly
needing to lift a finger.

>> You know, I don't believe you actually know how to do this under plain
>> Windows! Otherwise you would have done so; you must know that's what I
>> use.)
>>
>
> By /my/ ruling, any system with "bcc" or "tcc" is not plain Windows.
> Therefore you failed.

Huh? Those are compilers. You need a C compiler to turn .c files into
.exe files. You don't need that other crap.

>> So, what have /you/ achieved?
>>
>
> I did exactly what you claimed was impossible

I said when I tried it, it failed.

> - used "make" to build Lua on windows.

So did I in the end. But I'd long since done it anyway:

* Without even needing the 'proper' source file bundle: the Github
version was fine

* Without using 'make' or the right makefile

* Without using MSYS2 or CYGWIN

* Without using WSL

All in all I did better without using 'make'. I could even switch
instantly between GCC and TCC.

AND I built in with my BCC, which cannot be used from a makefile, not
the one here anyway, because it expects a C compiler to work in a
certain way.

[Keith Thompson]

Bart <b...@freeuk.com> writes:
> On 15/08/2023 22:09, David Brown wrote:
>> On 15/08/2023 19:49, Bart wrote:
>>> You know, one thing is going 100% certain in this thread: you are
>>> never for one minute going to admit that I'm right in there being
>>> something wrong with those Github ZIPs.
>>>
>>> You didn't see the problem because you either obtained the source
>>> bundle elsewhere, or would have used only the .tar.gz version.
>>>
>>
>> Look, I have no idea if these are the same or different. I don't know,
>> and don't care. The only reason I was at the lua website at all was
>> because /you/ picked it as something that "proves" that make never works
>> on Windows. I went to the lua website, followed the instructions on how
>> to build lua on Windows, and it worked - using "make". /You/ did not
>> not follow the instructions,
>
> I downloaded an open source project like I've done a hundred others:
> from Github. It's usually expected to have everything needed to build
> the project, except for the actual tools.

And now you've learned that the "release" .tar.gz and .zip files
provided by GitHub are just snapshots of the git repo. Official source
releases are often generated from the git repo, with things like
documentation and configure scripts generated by the maintainers of the
project. Whether you can easily build something from a GitHub release
file depends on the project.

I suspect you resorted to the GitHub "release" files because lua.org
doesn't provide a zip file.

It's an understandable error -- and it gave you an excuse to complain
and insult people.

[Bart]

But it's not understood by David Brown, and it gave him an excuse to
insult /me/.

In his book, it's impossible for anything to go wrong, so if I can't get
something to work, it HAS to be my fault. It can NEVER be the extra
opportunities for error that complex makefiles provide, or even simple ones.

No docs are too obscure or misleading (like lumping the 'mingw'
parameter needed for Windows under Unix-like systems)

And if can't make something work under ordinary Windows, my mistake is
not using Linux-like layers to keep the build process happy.

If even he has trouble pinning something on me (maybe somebody else
encountered the problem!) then of course it's because Windows is rubbish.

So, basically, I cannot win.

[Bart]

On 15/08/2023 14:22, Malcolm McLean wrote:
> On Tuesday, 15 August 2023 at 13:15:38 UTC+1, Bart wrote:
>> On 15/08/2023 11:53, Malcolm McLean wrote:
>>> On Tuesday, 15 August 2023 at 11:45:39 UTC+1, Bart wrote:
>>
>>>> I downloaded CMake to build Malcolm's project. I followed the
>>>> instructions and it didn't work.
>>>>
>>>> So, what do you want ME to do about that? Say that it is great anyway? I
>>>> say what I see.
>>>>
>>>> This project can be built trivially using:
>>>>
>>>> gcc *.c freetype\*.c samplerate\*.c
>>>>
>>>> So What Is The Point of using a heavyweight product like CMake? Try
>>>> selling THAT to me!
>>>>
>>> Well I'm the person responsible for that failure.
>>> Thank you very much for finding out that the instructions didn't work. I'm very close
>>> to packaging everything up into a release, and I don't want to release it with
>>> instructions that don't work.
>> My comment was a compliment not a criticism!
>>
>> Yes, there was implied criticism of CMake, but it was only highlighting
>> that having a complex dependency brings extra ways to fail.
>>
> Of course. So what went wrong?

I posted the results. But can't find that post (it was in that very long
thread), and I no longer have CMake.

But the gist of the main error was that it couldn't open 'nmake'. (There
were other things about something being deprecated.)

I don't know whether it expects that utility to be present, or why it
needs it, since the cmakelists.txt file didn't mention it.

If it is that, try hiding/renaming 'nmake' on your system (check by
typing 'nmake') to try and force the error.

[Kaz Kylheku]

The main C cross-platform problem between POSIX and Windows isn't
building, but the platforms being vastly different.

One way to port POSIX programs to Windows is to have a run-time
environment that has the needed POSIX support.

The projects which provide that tend to have the build environment also,
and of course that also helps.

If the library functions were there, but no build environment with make and
shell, that would be inconvenient. But less inconvenient than the
reverse: having the build environment, but crap POSIX libraries (situation with
all versions of MinGW).

I use Cygwin for building the Windows version of the TXR language.

For the run-time, I created a project which forks the Cygwin run-time.
I made some key alterations in the CYGWIN1.DLL to claw back some
of the ways in which the middleware emulates POSIX a little bit too
far.

The project is here:

https://www.kylheku.com/cygnal/

Cygnal makes it as easy as "humanly possible" to port your
Unix and Linux programs to Windows, and ship them to the users
such that the programs exhibit native-like conventions.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazi...@mstdn.ca

[David Brown]

On 16/08/2023 00:36, Bart wrote:
>
> On 15/08/2023 22:09, David Brown wrote:
> > On 15/08/2023 19:49, Bart wrote:
> >
> >> You know, one thing is going 100% certain in this thread: you are
> >> never for one minute going to admit that I'm right in there being
> >> something wrong with those Github ZIPs.
> >>
> >> You didn't see the problem because you either obtained the source
> >> bundle elsewhere, or would have used only the .tar.gz version.
> >>
> >
> > Look, I have no idea if these are the same or different.  I don't know,
> > and don't care.  The only reason I was at the lua website at all was
> > because /you/ picked it as something that "proves" that make never works
> > on Windows.  I went to the lua website, followed the instructions on how
> > to build lua on Windows, and it worked - using "make".  /You/ did not
> > not follow the instructions,
>
> I downloaded an open source project like I've done a hundred others:
> from Github. It's usually expected to have everything needed to build
> the project, except for the actual tools.
>
> > and you got in trouble.  No doubt you'd
> > have got in trouble even if you did follow the instructions, because you
> > are always so determined to have everything fail.
>
> You don't see the failures because most open source software is
> developed for Unix-like OSes, so build systems are well-tested because
> so many will be using that and will have reported failures.
>

I use both Windows and Linux. I aim to use the system that is the best
choice for the task in hand, though of course many things can be done
equally on both. Like most people, I use the software I find most
convenient and most appropriate for the things I want to do and the way
I want to work. I have "msys2" on my Windows system - it is not
"cheating", or "not proper Windows", or "hiding" - it is a package made
for Windows that provides tools that some people find useful. Nothing
more, nothing less. Similarly, I have "wine" installed on my Linux
systems so that I can run Windows programs there - that is not cheating,
or "not proper Linux".

And when people want to install software to use on Windows or Linux, how
many want to compile the software from source in order to use the
software (as distinct from modify it or copy parts of it)? I'd guess
that for Linux, the figure is less than 0.1% of users - and for Windows,
0.01% or fewer. Virtually everyone wanting Lua on Windows will download
a binary installer. Virtually everyone wanting Lua on Linux will use
their package manager - "yum install lua", "apt-get install lua", or
whatever gui they like for their particular distribution. Even people
using source-based Linux distributions like Gentoo will not see that the
source code is downloaded and compiled on their system.

Building projects from source code is not always easy, and often does
not have detailed information about requirements, because it is not
something many people do, and those who do it, are usually experienced
developers. Github source code is for developers, not users, and it is
expected that people are seriously interested in the project and willing
to spend time reading documentation and learning about it. People go to
the lua github page because they are interested in lua development -
maybe adding extensions, or reporting issues, or looking at integrating
it as a scripting language in their own code. The contributors to the
github site are interested in enhancing and improving the lua compiler,
interpreter, runtime and libraries - they are not going to waste their
time writing idiot's guide to compiling on Windows. And they are not
interested in people who want to build the software just so that they
can say it compiled - they are interested in people who want to /use/
the software.


You appear to be under a misconception that the world revolves around
/you/, that everyone else should go out of their way to make life as
simple as possible for you and your peculiar and unique needs, and that
those who do not, are personally attacking you. I suspect you still
don't understand how unusual your position is - no matter how often you
find yourself at odds with everyone else in discussion threads.

> In addition, even for software that runs on Windows, you hide behind a
> wall of Linux utilities; using MSYS2 or WSL.
>
> So really, it's not surprising that everything works for you with hardly
> needing to lift a finger.

I try to make things work. /You/ try to make things fail. We both succeed.

>
> >> You know, I don't believe you actually know how to do this under plain
> >> Windows! Otherwise you would have done so; you must know that's what I
> >> use.)
> >>
> >
> > By /my/ ruling, any system with "bcc" or "tcc" is not plain Windows.
> > Therefore you failed.
>
> Huh? Those are compilers. You need a C compiler to turn .c files into
> .exe files. You don't need that other crap.
>

It's exactly the same - tools for the job.

>
> >> So, what have /you/ achieved?
> >>
> >
> > I did exactly what you claimed was impossible
>
> I said when I tried it, it failed.

No, /you/ failed to use "make". So really, you succeeded, since failure
was your goal. Well done.

[Malcolm McLean]

My understanding of Lua is that, whilst it can be used as a standalone
language, it's really meant for adding scripting to applications. If you're
writing the game level editor then of course the programmer works
closely with the users, and it's acceptable to have the level editor
call a binary executable. But if you want scripting in the game itself then
you have to include the Lua source code.

S yes, users rather than developers of Lua itself have to be able to
incorporate it into a project and compile it easily.

[David Brown]

Actually, I am not sure it is an understandable error for Bart. In one
sense, Bart does not understand his error. In another sense, he is
familiar with github - he most certainly should know that it is for
development, and that code found there is often in flux, while released
versions from the project website will be more tested and more
appropriate for general use. And it is not understandable that he is
scared of tarballs.

> But it's not understood by David Brown, and it gave him an excuse to
> insult /me/.
>
> In his book, it's impossible for anything to go wrong, so if I can't get
> something to work, it HAS to be my fault. It can NEVER be the extra
> opportunities for error that complex makefiles provide, or even simple
> ones.

Oh, many things can go wrong. And it is quite possible for things to go
wrong that are /not/ your fault. But when you claim you're giving
things a fair test, yet fail to follow the simplest and most basic
instructions (despite being helped with pointers), that's not a fair
test. That is a determined intention to fail. (You are far too smart
and experienced to use inability or ignorance as an excuse.)

>
> No docs are too obscure or misleading (like lumping the 'mingw'
> parameter needed for Windows under Unix-like systems)
>
> And if can't make something work under ordinary Windows, my mistake is
> not using Linux-like layers to keep the build process happy.
>
> If even he has trouble pinning something on me (maybe somebody else
> encountered the problem!) then of course it's because Windows is rubbish.
>
> So, basically, I cannot win.
>

You can't win until you decide to try to listen, learn, experiment, and
progress as a developer. As long as your goal is to convince yourself
that the entire software world, other than yourself, is wrong, and all
tools other than your home-made systems are useless, unworkable and
unnecessary, then no - you cannot win.

No one is asking you to like C, gcc, make, Linux, or any other of your
pet hates. But it would be nice if you stopped spreading shite about them.

Maybe try asking "How can I do XXX in C?" rather than "I can't/won't do
XXX in C, therefore it is an unusable disaster and my own language is
pure genius". Wouldn't that make a nice change, and make threads a bit
more friendly and useful?

[David Brown]

It did not surprise me at all that they are different - github is
primarily for development, not standard tested releases. If you want to
download a proper release for a project, you go to the project website,
and follow the pointers there. (For some projects, the github pages and
readme.md /is/ the main website - but that is clearly not the case here.)

However, it did surprise me that the GitHub repository is /so/ different
from the released tarballs from the main site. The directory structures
are different, and the makefiles are significantly different - in the
release tarballs, they are aimed at configuring and installing (thus
having things like platform selection options), while in the GitHub they
are aimed at development (so lots of warning flags). The actual source
files seem the same.

>
>> That doesn't bother you I guess. Although this won't stop DB, who will
>> claim that of course I should have known that different kinds of
>> source 'tarballs' exist for the version of product, and only some of
>> them will work with the given build instructions.
>>
>> Although I did mention Github regarding Lua two days ago; you'd think
>> someone would have told me that was the wrong site to download source
>> code from, if it's so bleeding obvious.
>
> It's not obvious, and nobody has said that it is. I would have assumed
> that the release .tar.gz file from GitHub was similar to the .tar.gz
> file from lua.org until I checked.

Note, however, that people /did/ tell Bart to look at the build
instructions on the Lua site (including suggesting looking at the
"Detailed instructions").

And in the GitHub page, there is an "About" that says "The Lua
development repository, as seen by the Lua team. Mirrored irregularly."
There's a link to the project site.

[David Brown]

Certainly embedding it within other applications is a major purpose of
the language, yes. It is becoming more mature as a stand-alone
language, with more libraries, but it is very popular for adding to
other programs. As you say, Lua is a common choice for scripting in
games. I used it myself as a scripting language in an embedded program,
many moons ago.

> If you're
> writing the game level editor then of course the programmer works
> closely with the users, and it's acceptable to have the level editor
> call a binary executable. But if you want scripting in the game itself then
> you have to include the Lua source code.
>
> S yes, users rather than developers of Lua itself have to be able to
> incorporate it into a project and compile it easily.
>

Sure. But if you want to do that, you read the relevant sections of the
manual and see which files you need, which options you want, what
configuration you want, and how you should combine it with your own
code. You need to know how to integrate Lua with your code - how your
application will start the Lua runtime or call Lua code, how the Lua
code will call /your/ functions (in C or whatever), how to wrap your
functions, variables, classes, etc., into Lua tables and functions.
There is a lot involved here - it's not a "download and compile" task.
But then, you wouldn't be doing this unless you actually wanted to use
Lua in your program and are willing to invest the effort to do so.

[Malcolm McLean]

I wonder if it's the answer for the problem of how to specify the output
format of pixels in the Baby X resource compiler?. It's a very heavy-weight
solution. But it would provide the necessary flexibility.

[David Brown]

I can't remember the details of your post either (there's been a lot of
activity here recently). But were you attempting to install CMake on
Windows, or to /build/ CMake on Windows? Requiring "nmake" suggests you
were trying to build it - and the CMake website says you need an
existing binary of CMake in order to build CMake on Windows. (Yes, you
read that correctly. Please do not shoot the messenger.) The normal
way to get CMake on Windows, as on any platform, is to download a
pre-built binary.

[Bart]

On 16/08/2023 10:37, David Brown wrote:
> On 16/08/2023 02:05, Bart wrote:
>> But it's not understood by David Brown, and it gave him an excuse to
>> insult /me/.
>>
>> In his book, it's impossible for anything to go wrong, so if I can't
>> get something to work, it HAS to be my fault. It can NEVER be the
>> extra opportunities for error that complex makefiles provide, or even
>> simple ones.
>
> Oh, many things can go wrong. And it is quite possible for things to go
> wrong that are /not/ your fault. But when you claim you're giving
> things a fair test, yet fail to follow the simplest and most basic
> instructions (despite being helped with pointers), that's not a fair
> test.

I like how you tried desperately to make it all my fault. Oh, you should
have known this, should have known that. I bet you were surprised that
that Github repository was incomplete too!

> That is a determined intention to fail. (You are far too smart
> and experienced to use inability or ignorance as an excuse.)

You know, it really doesn't help when every makefile is called
'makefile'. Having specific names would have picked up my issue
instantly, since that particular project used two separate makefiles
both called 'makefile'.

You also know that that is a jolly good idea, but of course will never
admit it in a million years.

> You can't win until you decide to try to listen, learn, experiment, and
> progress as a developer.

You need to work a little more on being patronising.

> As long as your goal is to convince yourself
> that the entire software world, other than yourself, is wrong, and all
> tools other than your home-made systems are useless, unworkable and
> unnecessary, then no - you cannot win.

My battle is against unnecessary complex and bloat.

I like elegance and consistency in a programming language. I also like
that lessons are learned and things are improved.

I don't like elaborate solutions when simpler ones are far better.

I don't like clumsy, slow, error prone processes.

You're right that no one uses my stuff, but so what? You can think of it
as proof of concept that simpler, more elegant and more fool-proof
solutions can work.

Lua as a project is about the same size as many of mine. If written in
my language, the build process to creating lua.exe would be:

mm lua

The same on Linux if mm was ported there. (I have done that, the process
was ./mm lua). To create separate .exe and .dll, it might instead be 'mm
luac && mm -dll lualib'.

You can still use makefiles if you wish; they'd be rather short!

So my solutions are far advanced that the ones you use for C. You're
asking me, a developer, to step back a couple of decades to use obsolete
tools that people have been stuck with the same reasons that they have
to use -lm and get around a.out.

These days I'm more of a developer of languages than apps. And I
concentrate on aspects of language implementations that many ignore,
such as size, compactness, self-containment, speed, usability and
simplicity of the tool itself.

In short, I'm not a conformist.

> No one is asking you to like C, gcc, make, Linux, or any other of your
> pet hates. But it would be nice if you stopped spreading shite about
them.
>
> Maybe try asking "How can I do XXX in C?" rather than "I can't/won't do
> XXX in C, therefore it is an unusable disaster and my own language is
> pure genius". Wouldn't that make a nice change, and make threads a bit
> more friendly and useful?

You can't change the language C. But most of this discussion has been on
aspects that are peripheral to the language, like those I touched on
above. And there things could be done differently.

Of course, you are NEVER going to admit that doing:

mm lua

might be a touch sweeter than those 330 lines of makefile crap below.

You can't do that in C, so there I used a solution what was 33 lines,
exactly 1/10th the size of the combined makefiles.

So, I'm on a hiding to nothing. You will always be convinced that I'm
some deviant that needs to brainwashed into taking the correct path and
having the right subservient attitudes, a bit like the protagonist at
the end of /1984/.

In any case, I'm done. I've deleted all my C compilers and all my C
related projects.

Including mine. But I'm keeping a ZIP in case I want to maintain it as a
test program; it's one of the best I have for my own language. Although
since it is for a C subset, I may develop that aspect, change it some
more, and give that language a different name.

Thank you for making 'C' and its development methods (and the attitudes
of its adherents) so unpalatable that I'm finally able to take that break.

(I'm still available for testing build systems, since I have a knack for
finding problems that seem to slip by everyone else!)

--------------------------------------------------------


# Makefile for installing Lua
# See doc/readme.html for installation and customization instructions.

# == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT
=======================

# Your platform. See PLATS for possible values.
PLAT= guess

# Where to install. The installation starts in the src and doc directories,
# so take care if INSTALL_TOP is not an absolute path. See the local target.
# You may want to make INSTALL_LMOD and INSTALL_CMOD consistent with
# LUA_ROOT, LUA_LDIR, and LUA_CDIR in luaconf.h.
INSTALL_TOP= /usr/local
INSTALL_BIN= $(INSTALL_TOP)/bin
INSTALL_INC= $(INSTALL_TOP)/include
INSTALL_LIB= $(INSTALL_TOP)/lib
INSTALL_MAN= $(INSTALL_TOP)/man/man1
INSTALL_LMOD= $(INSTALL_TOP)/share/lua/$V
INSTALL_CMOD= $(INSTALL_TOP)/lib/lua/$V

# How to install. If your install program does not support "-p", then
# you may have to run ranlib on the installed liblua.a.
INSTALL= install -p
INSTALL_EXEC= $(INSTALL) -m 0755
INSTALL_DATA= $(INSTALL) -m 0644
#
# If you don't have "install" you can use "cp" instead.
# INSTALL= cp -p
# INSTALL_EXEC= $(INSTALL)
# INSTALL_DATA= $(INSTALL)

# Other utilities.
MKDIR= mkdir -p
RM= rm -f

# == END OF USER SETTINGS -- NO NEED TO CHANGE ANYTHING BELOW THIS LINE
=======

# Convenience platforms targets.
PLATS= guess aix bsd c89 freebsd generic ios linux linux-readline macosx
mingw posix solaris

# What to install.
TO_BIN= lua luac
TO_INC= lua.h luaconf.h lualib.h lauxlib.h lua.hpp
TO_LIB= liblua.a
TO_MAN= lua.1 luac.1

# Lua version and release.
V= 5.4
R= $V.6

# Targets start here.
all: $(PLAT)

$(PLATS) help test clean:
@cd src && $(MAKE) $@

install: dummy
cd src && $(MKDIR) $(INSTALL_BIN) $(INSTALL_INC) $(INSTALL_LIB)
$(INSTALL_MAN) $(INSTALL_LMOD) $(INSTALL_CMOD)
cd src && $(INSTALL_EXEC) $(TO_BIN) $(INSTALL_BIN)
cd src && $(INSTALL_DATA) $(TO_INC) $(INSTALL_INC)
cd src && $(INSTALL_DATA) $(TO_LIB) $(INSTALL_LIB)
cd doc && $(INSTALL_DATA) $(TO_MAN) $(INSTALL_MAN)

uninstall:
cd src && cd $(INSTALL_BIN) && $(RM) $(TO_BIN)
cd src && cd $(INSTALL_INC) && $(RM) $(TO_INC)
cd src && cd $(INSTALL_LIB) && $(RM) $(TO_LIB)
cd doc && cd $(INSTALL_MAN) && $(RM) $(TO_MAN)

local:
$(MAKE) install INSTALL_TOP=../install

# make may get confused with install/ if it does not support .PHONY.
dummy:

# Echo config parameters.
echo:
@cd src && $(MAKE) -s echo
@echo "PLAT= $(PLAT)"
@echo "V= $V"
@echo "R= $R"
@echo "TO_BIN= $(TO_BIN)"
@echo "TO_INC= $(TO_INC)"
@echo "TO_LIB= $(TO_LIB)"
@echo "TO_MAN= $(TO_MAN)"
@echo "INSTALL_TOP= $(INSTALL_TOP)"
@echo "INSTALL_BIN= $(INSTALL_BIN)"
@echo "INSTALL_INC= $(INSTALL_INC)"
@echo "INSTALL_LIB= $(INSTALL_LIB)"
@echo "INSTALL_MAN= $(INSTALL_MAN)"
@echo "INSTALL_LMOD= $(INSTALL_LMOD)"
@echo "INSTALL_CMOD= $(INSTALL_CMOD)"
@echo "INSTALL_EXEC= $(INSTALL_EXEC)"
@echo "INSTALL_DATA= $(INSTALL_DATA)"

# Echo pkg-config data.
pc:
@echo "version=$R"
@echo "prefix=$(INSTALL_TOP)"
@echo "libdir=$(INSTALL_LIB)"
@echo "includedir=$(INSTALL_INC)"

# Targets that do not create files (not all makes understand .PHONY).
.PHONY: all $(PLATS) help test clean install uninstall local dummy echo pc

# (end of Makefile)
# Makefile for building Lua
# See ../doc/readme.html for installation and customization instructions.

# == CHANGE THE SETTINGS BELOW TO SUIT YOUR ENVIRONMENT
=======================

# Your platform. See PLATS for possible values.
PLAT= guess

CC= gcc -std=gnu99
CFLAGS= -O2 -Wall -Wextra -DLUA_COMPAT_5_3 $(SYSCFLAGS) $(MYCFLAGS)
LDFLAGS= $(SYSLDFLAGS) $(MYLDFLAGS)
LIBS= -lm $(SYSLIBS) $(MYLIBS)

AR= ar rcu
RANLIB= ranlib
RM= rm -f
UNAME= uname

SYSCFLAGS=
SYSLDFLAGS=
SYSLIBS=

MYCFLAGS=
MYLDFLAGS=
MYLIBS=
MYOBJS=

# Special flags for compiler modules; -Os reduces code size.
CMCFLAGS=

# == END OF USER SETTINGS -- NO NEED TO CHANGE ANYTHING BELOW THIS LINE
=======

PLATS= guess aix bsd c89 freebsd generic ios linux linux-readline macosx
mingw posix solaris

LUA_A= liblua.a
CORE_O= lapi.o lcode.o lctype.o ldebug.o ldo.o ldump.o lfunc.o lgc.o
llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o
ltm.o lundump.o lvm.o lzio.o
LIB_O= lauxlib.o lbaselib.o lcorolib.o ldblib.o liolib.o lmathlib.o
loadlib.o loslib.o lstrlib.o ltablib.o lutf8lib.o linit.o
BASE_O= $(CORE_O) $(LIB_O) $(MYOBJS)

LUA_T= lua
LUA_O= lua.o

LUAC_T= luac
LUAC_O= luac.o

ALL_O= $(BASE_O) $(LUA_O) $(LUAC_O)
ALL_T= $(LUA_A) $(LUA_T) $(LUAC_T)
ALL_A= $(LUA_A)

# Targets start here.
default: $(PLAT)

all: $(ALL_T)

o: $(ALL_O)

a: $(ALL_A)

$(LUA_A): $(BASE_O)
$(AR) $@ $(BASE_O)
$(RANLIB) $@

$(LUA_T): $(LUA_O) $(LUA_A)
$(CC) -o $@ $(LDFLAGS) $(LUA_O) $(LUA_A) $(LIBS)

$(LUAC_T): $(LUAC_O) $(LUA_A)
$(CC) -o $@ $(LDFLAGS) $(LUAC_O) $(LUA_A) $(LIBS)

test:
./$(LUA_T) -v

clean:
$(RM) $(ALL_T) $(ALL_O)

depend:
@$(CC) $(CFLAGS) -MM l*.c

echo:
@echo "PLAT= $(PLAT)"
@echo "CC= $(CC)"
@echo "CFLAGS= $(CFLAGS)"
@echo "LDFLAGS= $(LDFLAGS)"
@echo "LIBS= $(LIBS)"
@echo "AR= $(AR)"
@echo "RANLIB= $(RANLIB)"
@echo "RM= $(RM)"
@echo "UNAME= $(UNAME)"

# Convenience targets for popular platforms.
ALL= all

help:
@echo "Do 'make PLATFORM' where PLATFORM is one of these:"
@echo " $(PLATS)"
@echo "See doc/readme.html for complete instructions."

guess:
@echo Guessing `$(UNAME)`
@$(MAKE) `$(UNAME)`

AIX aix:
$(MAKE) $(ALL) CC="xlc" CFLAGS="-O2 -DLUA_USE_POSIX -DLUA_USE_DLOPEN"
SYSLIBS="-ldl" SYSLDFLAGS="-brtl -bexpall"

bsd:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN"
SYSLIBS="-Wl,-E"

c89:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_C89" CC="gcc -std=c89"
@echo ''
@echo '*** C89 does not guarantee 64-bit integers for Lua.'
@echo '*** Make sure to compile all external Lua libraries'
@echo '*** with LUA_USE_C89 to ensure consistency'
@echo ''

FreeBSD NetBSD OpenBSD freebsd:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX -DLUA_USE_READLINE
-I/usr/include/edit" SYSLIBS="-Wl,-E -ledit" CC="cc"

generic: $(ALL)

ios:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_IOS"

Linux linux: linux-noreadline

linux-noreadline:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-Wl,-E -ldl"

linux-readline:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX -DLUA_USE_READLINE"
SYSLIBS="-Wl,-E -ldl -lreadline"

Darwin macos macosx:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_MACOSX -DLUA_USE_READLINE"
SYSLIBS="-lreadline"

mingw:
$(MAKE) "LUA_A=lua54.dll" "LUA_T=lua.exe" \
"AR=$(CC) -shared -o" "RANLIB=strip --strip-unneeded" \
"SYSCFLAGS=-DLUA_BUILD_AS_DLL" "SYSLIBS=" "SYSLDFLAGS=-s" lua.exe
$(MAKE) "LUAC_T=luac.exe" luac.exe

posix:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX"

SunOS solaris:
$(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_POSIX -DLUA_USE_DLOPEN
-D_REENTRANT" SYSLIBS="-ldl"

# Targets that do not create files (not all makes understand .PHONY).
.PHONY: all $(PLATS) help test clean default o a depend echo

# Compiler modules may use special flags.
llex.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c llex.c

lparser.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c lparser.c

lcode.o:
$(CC) $(CFLAGS) $(CMCFLAGS) -c lcode.c

# DO NOT DELETE

lapi.o: lapi.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h lstring.h \
ltable.h lundump.h lvm.h
lauxlib.o: lauxlib.c lprefix.h lua.h luaconf.h lauxlib.h
lbaselib.o: lbaselib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lcode.o: lcode.c lprefix.h lua.h luaconf.h lcode.h llex.h lobject.h \
llimits.h lzio.h lmem.h lopcodes.h lparser.h ldebug.h lstate.h ltm.h \
ldo.h lgc.h lstring.h ltable.h lvm.h
lcorolib.o: lcorolib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lctype.o: lctype.c lprefix.h lctype.h lua.h luaconf.h llimits.h
ldblib.o: ldblib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ldebug.o: ldebug.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h lcode.h llex.h lopcodes.h lparser.h \
ldebug.h ldo.h lfunc.h lstring.h lgc.h ltable.h lvm.h
ldo.o: ldo.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h lopcodes.h \
lparser.h lstring.h ltable.h lundump.h lvm.h
ldump.o: ldump.c lprefix.h lua.h luaconf.h lobject.h llimits.h lstate.h \
ltm.h lzio.h lmem.h lundump.h
lfunc.o: lfunc.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h
lgc.o: lgc.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h lstring.h ltable.h
linit.o: linit.c lprefix.h lua.h luaconf.h lualib.h lauxlib.h
liolib.o: liolib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
llex.o: llex.c lprefix.h lua.h luaconf.h lctype.h llimits.h ldebug.h \
lstate.h lobject.h ltm.h lzio.h lmem.h ldo.h lgc.h llex.h lparser.h \
lstring.h ltable.h
lmathlib.o: lmathlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lmem.o: lmem.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h
loadlib.o: loadlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lobject.o: lobject.c lprefix.h lua.h luaconf.h lctype.h llimits.h \
ldebug.h lstate.h lobject.h ltm.h lzio.h lmem.h ldo.h lstring.h lgc.h \
lvm.h
lopcodes.o: lopcodes.c lprefix.h lopcodes.h llimits.h lua.h luaconf.h
loslib.o: loslib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lparser.o: lparser.c lprefix.h lua.h luaconf.h lcode.h llex.h lobject.h \
llimits.h lzio.h lmem.h lopcodes.h lparser.h ldebug.h lstate.h ltm.h \
ldo.h lfunc.h lstring.h lgc.h ltable.h
lstate.o: lstate.c lprefix.h lua.h luaconf.h lapi.h llimits.h lstate.h \
lobject.h ltm.h lzio.h lmem.h ldebug.h ldo.h lfunc.h lgc.h llex.h \
lstring.h ltable.h
lstring.o: lstring.c lprefix.h lua.h luaconf.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h ldo.h lstring.h lgc.h
lstrlib.o: lstrlib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ltable.o: ltable.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h lstring.h ltable.h lvm.h
ltablib.o: ltablib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
ltm.o: ltm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lgc.h lstring.h ltable.h lvm.h
lua.o: lua.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
luac.o: luac.c lprefix.h lua.h luaconf.h lauxlib.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h lopcodes.h lopnames.h lundump.h
lundump.o: lundump.c lprefix.h lua.h luaconf.h ldebug.h lstate.h \
lobject.h llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lstring.h lgc.h \
lundump.h
lutf8lib.o: lutf8lib.c lprefix.h lua.h luaconf.h lauxlib.h lualib.h
lvm.o: lvm.c lprefix.h lua.h luaconf.h ldebug.h lstate.h lobject.h \
llimits.h ltm.h lzio.h lmem.h ldo.h lfunc.h lgc.h lopcodes.h lstring.h \
ltable.h lvm.h ljumptab.h
lzio.o: lzio.c lprefix.h lua.h luaconf.h llimits.h lmem.h lstate.h \
lobject.h ltm.h lzio.h

# (end of Makefile)

[Bart]

CMake was installed, and the path to its main .exe file was in the PATH
variable.

I used Malcolm's instructions to build his project using CMake.

[David Brown]

If you are looking at Lua, then you could go a lot further than that.
For one thing, you could write the whole resource compiler in Lua - it
would be simpler and shorter than doing it in C. There are XML parsing
libraries in Lua.

You could also use Lua as the format for your configuration files,
rather than XML. I have often used Python as the configuration format
for Python programs I have written - then reading the configuration is
just an "import", without any need to make parsers. (Of course, you
have to be able to trust the users and the configuration file writers in
such cases.) This is particularly handy if you want loops or other
calculated configuration - if a resource configuration file is supposed
to include "image000.png" up to "image999.png", it's a lot easier in Lua
than doing a thousand copy-paste-edit operations in an XML file!

[David Brown]

On 16/08/2023 13:15, Bart wrote:
> On 16/08/2023 10:37, David Brown wrote:
> > On 16/08/2023 02:05, Bart wrote:
> >> But it's not understood by David Brown, and it gave him an excuse to
> >> insult /me/.
> >>
> >> In his book, it's impossible for anything to go wrong, so if I can't
> >> get something to work, it HAS to be my fault. It can NEVER be the
> >> extra opportunities for error that complex makefiles provide, or even
> >> simple ones.
> >
> > Oh, many things can go wrong.  And it is quite possible for things to go
> > wrong that are /not/ your fault.  But when you claim you're giving
> > things a fair test, yet fail to follow the simplest and most basic
> > instructions (despite being helped with pointers), that's not a fair
> > test.
>
> I like how you tried desperately to make it all my fault.

I am not desparate. I tried to tell you what you did wrong, so that you
could try to get it right. Since you repeatedly ignore that, I condense
it to saying you were wrong.

> Oh, you should
> have known this, should have known that. I bet you were surprised that
> that Github repository was incomplete too!

I wrote exactly that in a reply to Keith (which you might not have read
yet).

So I /do/ understand that you also found that surprising, and I don't
think it is an unreasonable guess, before reading anything about a given
project, to suppose that a GitHub repository connected to a project
would have the same files that are provided in releases of the project.

But understanding how you got this wrong does not mean you did not get
it wrong.

And since the GitHub page and readme contains multiple indications that
you should be looking at "www.lua.org" for downloads and build and
install instructions, and you were told in posts here about such
instructions, it becomes your /fault/ that you remained wrong.

You prefered to stay wrong, so that you could complain about problems
building the project - you never had any intention of trying to get it
right, and thus actively avoided doing so. That makes it your fault.

>
> >  That is a determined intention to fail.  (You are far too smart
> > and experienced to use inability or ignorance as an excuse.)
>
> You know, it really doesn't help when every makefile is called
> 'makefile'. Having specific names would have picked up my issue
> instantly, since that particular project used two separate makefiles
> both called 'makefile'.

No, it does not. In the release tarballs, there are two separate files
- "Makefile" and "src/Makefile". Directories are relevant.

If you "organise" your code the way you said you do, with hundreds of
different unrelated files in one directory, then I can see why you would
dislike a common name like "makefile". But for people who organise
their projects and code in directories, a single common name is perfect
- "makefile", "README.md", etc.

>
> You also know that that is a jolly good idea, but of course will never
> admit it in a million years.

When I have multiple makefiles in a single directory (sometimes I will
split a makefile into multiple parts, separating project-specific,
host-specific and generic sections) I give them different names.

But what would be the benefit of different names in this case? They are
clearly different files when they are in different directories. Calling
them "makefile" (or "Makefile") makes it immediately obvious what the
files are. If they were called "install.mk" and "build.mk" instead,
people would wonder what they were, and where the makefile is, and they
would have to write "make -f install.mk" instead of just "make".

Tell me what you see as the advantage here, and why /you/ think it would
be a jolly good idea, and maybe I'll agree. But you have to say why it
would be better for everyone, not just for you personally - you need
good reasons to change 50 year old conventions.

>
> > You can't win until you decide to try to listen, learn, experiment, and
> > progress as a developer.
>
> You need to work a little more on being patronising.
>
> >  As long as your goal is to convince yourself
> > that the entire software world, other than yourself, is wrong, and all
> > tools other than your home-made systems are useless, unworkable and
> > unnecessary, then no - you cannot win.
>
> My battle is against unnecessary complex and bloat.

Why? For whom? Do you think you are achieving your goals here?

I mean, it's a noble aim. Don't misunderstand me - I /agree/ that all
other things being equal, it is better for software to be small, simple
and fast. The trouble with your position is that all other things are
/not/ equal. It is very rarely a good idea to target any particular
aspect to the extreme or to the exclusion of other things. Your
compiler may be much smaller and faster than gcc, but it does not have
the features people need. Writing "cc *.c" may be simpler than a
makefile, but it does not do the same thing.

Then there is the question of why it matters. PC disks are big. PC
CPUs are fast. Network speeds are high. Top quality development tools
and utilities are freely available - even on Windows. Size and speed
matters very little for software on PC's. (It matters a great deal on
small embedded systems.)

So who are you fighting for? Who are you fighting against? Do you
really think you are making a difference for some greater good here, or
even just for your own personal benefit? (There's nothing wrong with
doing it for your own benefit - I am not suggesting you have to fight
for other people.) Have you considered whether there are other battles
that would make more sense or have greater impact? Have you considered
forgetting it all, splashing out £300 on a new mini-PC, installing Linux
Mint, and going back to having fun with computers, learning new things,
and creating software without bothering about how much space gcc takes up?

I really don't understand your motivation for these pointless arguments
and battles - unless you simply enjoy the argument. You are not a
fanatic who thinks all software is evil unless written by your personal
religious cult, or that we'll all go back to C90 after the appocolypse.

>
> I like elegance and consistency in a programming language. I also like
> that lessons are learned and things are improved.
>
> I don't like elaborate solutions when simpler ones are far better.
>
> I don't like clumsy, slow, error prone processes.
>
> You're right that no one uses my stuff, but so what? You can think of it
> as proof of concept that simpler, more elegant and more fool-proof
> solutions can work.

But they /can't/ work - they don't do what people need. You /know/
this. You can write small and simple solutions for specific limited
use-cases - that's nothing new. But anything that will cover a wide
variety of needs of a wide variety of people is inevitably bigger and
more complex.

>
> Lua as a project is about the same size as many of mine. If written in
> my language, the build process to creating lua.exe would be:
>
>    mm lua
>
> The same on Linux if mm was ported there. (I have done that, the process
> was ./mm lua). To create separate .exe and .dll, it might instead be 'mm
> luac && mm -dll lualib'.
>
> You can still use makefiles if you wish; they'd be rather short!
>
> So my solutions are far advanced that the ones you use for C. You're
> asking me, a developer, to step back a couple of decades to use obsolete
> tools that people have been stuck with the same reasons that they have
> to use -lm and get around a.out.

No - I am asking you to understand the world is bigger than you.

You could design a television with one button - for turning it on and
off. That would be beautifully simple and elegant. Why do people want
the complexity of choosing channels when BBC 1 has all you need? What's
the point of a volume control when the hardware can be fixed at the
ideal volume level for your preferences?

But would that television work for other people? Would it be better?
Simple and limited are great for specific cases - and maybe that
television would be better for your needs. But it won't suit others,
and cannot be a wide-scale solution.

>
> These days I'm more of a developer of languages than apps. And I
> concentrate on aspects of language implementations that many ignore,
> such as size, compactness, self-containment, speed, usability and
> simplicity of the tool itself.
>
> In short, I'm not a conformist.

That's fine - be yourself, not anyone else.

But don't believe it makes you better in any way, or that it makes your
creations better, or that everyone else is wrong.

>
> > No one is asking you to like C, gcc, make, Linux, or any other of your
> > pet hates.  But it would be nice if you stopped spreading shite about
> them.
> >
> > Maybe try asking "How can I do XXX in C?" rather than "I can't/won't do
> > XXX in C, therefore it is an unusable disaster and my own language is
> > pure genius".  Wouldn't that make a nice change, and make threads a bit
> > more friendly and useful?
>
> You can't change the language C. But most of this discussion has been on
> aspects that are peripheral to the language, like those I touched on
> above. And there things could be done differently.

Don't you think people /would/ do things differently if they thought
things could be improved? Do you believe you are alone in considering
whether there might be alternative solutions or better ways to do
things? Do you imagine that you alone can see flaws in common tools?

Everyone who has ever used "make" seriously knows it is not perfect.
Lots of people have made alternatives or companion tools. Some, such as
CMake, have their fans, and others have particular niche uses and
features. Excluding IDE project build systems, none have come remotely
close to competing with make for market share. It turns out that for
all its flaws, "make" is good enough for a huge variety of use-cases,
and its ubiquity and familiarity trump its flaws. (It's like C, *nix,
and many other things in that respect.)

>
> Of course, you are NEVER going to admit that doing:
>
>   mm lua
>
> might be a touch sweeter than those 330 lines of makefile crap below.

I fail to see how that's better than "make" (or "make mingw" on
Windows). I /do/ see how "make" is vastly superior, because the
makefile has lots more in it than just the dependencies that could be
found automatically. Where does "mm lua" put all the compiler flags?
The pre-defined macros used to configure lua according to needs and
preferences? The alternative build targets for tests? The warning
flags? The choice of compiler? The comments and documentation?


Short and sweet is all well enough - /if/ it is good enough and has the
features that people want. "make" may be complex, but it does what is
needed.

And the makefile for Lua is hardly complex or difficult to follow.

>
> You can't do that in C, so there I used a solution what was 33 lines,
> exactly 1/10th the size of the combined makefiles.
>

There you go again - the unwarranted assumption that "smaller" is
"better". It is not. There is more to making good software than size.

> So, I'm on a hiding to nothing. You will always be convinced that I'm
> some deviant that needs to brainwashed into taking the correct path and
> having the right subservient attitudes, a bit like the protagonist at
> the end of /1984/.
>
> In any case, I'm done. I've deleted all my C compilers and all my C
> related projects.
>

What a truly silly thing to do. If someone told you your house was a
horrible colour, would you burn it down?

I'd make a copy of your archives while they are still functional.

[David Brown]

OK.

[Bart]

On 16/08/2023 14:16, David Brown wrote:

> On 16/08/2023 13:15, Bart wrote:
> I am not desparate. I tried to tell you what you did wrong, so that you
> could try to get it right. Since you repeatedly ignore that, I condense
> it to saying you were wrong.

And you are convinced that I must have been wrong, and that the blame
falls 100% on me.

I've spent a lot of time doing technical support with clients who were
endusers and encountered lots of different kinds of problems.

I got to have an idea of where things could be commonly or easily
misunderstood. I was also involved in writing user manuals and mine were
written with the possibility that things could go wrong and the
knowledge of which aspects could be misunderstood.

There was rarely a point where a customer was just plain stupid. If they
did something wrongly, I would see what I could change to make that less
likely and more foolproof.

Most manuals and references are written with the assumption that the
product is perfect, and so is the manual; it can never be ambiguous or
confusing.

> But understanding how you got this wrong does not mean you did not get
> it wrong.

It's not me! Building that product requires two makefiles, only one was
provided on that site.

So a bunch of .c and .h files, and a file called 'makefile'; hmmm.... Is
it not unreasonable for someone to make a wild stab and guess you built
the product using 'make'? Especially given the lack of the usual build
instructions.

The short readme does indeed say get releases from a website; but that
can be taken to mean (as I did) releases of binaries, since the Releases
section of the github page has only sources.

I take it that you wouldn't change that Readme at all just to make it a
bit clearer? After all lots of people will use 'github <appname>' to get
at the sources of projects.

But no, let's just leave it! Adding a few more lines of clarification to
a 6-line readme is too much effort.

>> might be a touch sweeter than those 330 lines of makefile crap below.
>
> I fail to see how that's better than "make" (or "make mingw" on
> Windows). I /do/ see how "make" is vastly superior, because the
> makefile has lots more in it than just the dependencies that could be
> found automatically. Where does "mm lua" put all the compiler flags?
> The pre-defined macros used to configure lua according to needs and
> preferences? The alternative build targets for tests? The warning
> flags? The choice of compiler?

'mm' /is/ the compiler, in the same way that 'cc' is the C compiler in
lots of similar examples in the rare cases that people invoke it directly.

I did say you can add a makefile if you want, or script it in any manner
you like. 'mm prog' takes care of locating the source files of a
project, which occupies most of a makefile. With that out of the way,
there is not a great deal left.

This is the script (putmm.bat) which builds a new version of mm using an
old version, then replaces that old version (backups are a separate script):

\m\mm mm -ext -opt
copy mm.exe \m\mm.exe

There are no intermediate files to clean up and no dependencies to worry
about.

'mm prog' turns a bunch of sources into one binary file. If an app is
more elaborfate than that, then some basic scripting might be needed to
invoke it more than once or copy files about etc.

Different configurations tend to have a differently named lead module.
Compiler options (there aren't many) can be added to the command line;
being options, you may not want them baked in.

The fundamental step is so simple, anyone can easily see how to apply
their own scripting for their needs.

> Short and sweet is all well enough - /if/ it is good enough and has the
> features that people want. "make" may be complex, but it does what is
> needed.

Suppose somebody wanted to know all the relevant files because they
wanted control of the whole build process? Or even, run their own
compiler that doesn't follow convention. That information is pretty much
opaque in makefiles; it's not meant to be human-readable.

(With mm, the relevant modules are listed in the lead module as part of
the module scheme. Support files, that used via 'include' or which are
embedded, are not listed in one place. But you can get a summary when
generating an amalgamated source file using -ma.)

> And the makefile for Lua is hardly complex or difficult to follow.

It's 331 lines for both of them. Can it be done better? Here's my stab
at it (based on one for Pico C as the Lua one is too abstruse):

# CC = tcc
CC = gcc

lua:
$(CC) -olua \
lua.c \
lapi.c \
lcode.c \
lctype.c \
ldebug.c \
ldo.c \
ldump.c \
lfunc.c \
lgc.c \
llex.c \
lmem.c \
lobject.c \
lopcodes.c \
lparser.c \
lstate.c \
lstring.c \
ltable.c \
ltm.c \
lundump.c \
lvm.c \
lzio.c \
lauxlib.c \
lbaselib.c \
lcorolib.c \
ldblib.c \
liolib.c \
lmathlib.c \
loadlib.c \
loslib.c \
lstrlib.c \
ltablib.c \
lutf8lib.c \
linit.c \
-lm

This had some problems with gcc, but it managed to produce executables
for both tcc and gcc. I had to run it under WSL, since my Windows at the
minute has problems running C compilers.

It is 4% the size of the two supplied makefiles: it's not just the
linecount; the latter are written horizontally. Any reason why they
can't list one file per line?

> What a truly silly thing to do. If someone told you your house was a
> horrible colour, would you burn it down?
>
> I'd make a copy of your archives while they are still functional.

It really doesn't matter. My main tools are still there, only the ones
which adversely affect my blood pressure are going.

[Bart]

On 16/08/2023 14:16, David Brown wrote:

> Tell me what you see as the advantage here, and why /you/ think it would
> be a jolly good idea, and maybe I'll agree. But you have to say why it
> would be better for everyone, not just for you personally - you need
> good reasons to change 50 year old conventions.

[Giving names to makefiles]

* You can have more than one project in the same folder

* You can have different configurations of the same project

* You can have different makefiles customised to different compilers
(Seed7 has nearly 20 different makefiles)

* You can split up a project into components with their own separately
invoked makefile

* You can differentiate between a makefile that is called directly,
and one that is called indirectly from another

* If you expected to build X according to the build instructions,
but the makefile is called Y, then you know something may be wrong

'make' must be unique in being an application that takes input from a
file, but the name of the file is hardcoded.

A few applications will use defaults when a filename is missing (even if
it's 'stdin'), but are generally used with a specific name.

I would actually make a missing filename an error for an application
like this.

Maybe make was written by the same person who hardcoded a.out as an
output filename. They missing a trick by not having a.c as the default
input for a C compiler; that makes as much sense.

[Bart]

I reinstalled CMake. The results I get are:


c:\bbx\build>cmake ..
CMake Deprecation Warning at CMakeLists.txt:5 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.

Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.


CMake Error at CMakeLists.txt:9 (project):
Running

'nmake' '-?'

failed with:

The system cannot find the file specified


CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!

[Bart]

Hmm, maybe it's talking about a file called '-?', which seems to be the
subject of the other thread.

It still leaves the question of why it's using nmake, which I don't have
on my machine either.

It also suggests that that error message, for a 112MB application, could
be a lot better: if a file is missing, WHICH file is it exactly?

BTW line 9 of cmakelists.txt is this line:

project(babyxrc)

[Scott Lurndal]

Bart <b...@freeuk.com> writes:
>On 16/08/2023 14:16, David Brown wrote:
> > Tell me what you see as the advantage here, and why /you/ think it would
> > be a jolly good idea, and maybe I'll agree. But you have to say why it
> > would be better for everyone, not just for you personally - you need
> > good reasons to change 50 year old conventions.

>'make' must be unique in being an application that takes input from a
>file, but the name of the file is hardcoded.

No, it is not. If you would trouble yourself to read the make manual
page, you'll find that:
1) the -f argument allows the specification of a arbitrary name for the
makefile.
2) Absent -f, make will look for 'makefile', 'GNUmakefile', or 'Makefile'.

$ man make

SYNOPSIS
make [ -f makefile ] [ options ] ... [ targets ] ...

...
Normally you should call your makefile either makefile or Makefile.
(We recommend Makefile because it appears prominently near the begin-
ning of a directory listing, right near other important files such as
README.) The first name checked, GNUmakefile, is not recommended for
most makefiles. You should use this name if you have a makefile that
is specific to GNU make, and will not be understood by other versions
of make. If makefile is `-', the standard input is read.
...
-f file, --file=file, --makefile=FILE
Use file as a makefile.

The usenet acronym 'RTFM' is always relevent.

[Scott Lurndal]

https://stackoverflow.com/questions/69338088/error-while-configuring-cmake-project-running-nmake-failed

[Bart]

On 16/08/2023 18:43, Scott Lurndal wrote:
> Bart <b...@freeuk.com> writes:
>> On 16/08/2023 14:16, David Brown wrote:
>>> Tell me what you see as the advantage here, and why /you/ think it would
>>> be a jolly good idea, and maybe I'll agree. But you have to say why it
>>> would be better for everyone, not just for you personally - you need
>>> good reasons to change 50 year old conventions.
>
>> 'make' must be unique in being an application that takes input from a
>> file, but the name of the file is hardcoded.
>
> No, it is not. If you would trouble yourself to read the make manual
> page, you'll find that:
> 1) the -f argument allows the specification of a arbitrary name for the
> makefile.
> 2) Absent -f, make will look for 'makefile', 'GNUmakefile', or 'Makefile'.

I know about -f because I've seen it.

But most documented uses of 'make' seem with work with the default
filename 'makefile'.

Most projects I've seen with a makefile, have a file called 'makefile'.

In the project that has been discussed, there were two makefiles both
called 'makefile'. In the erroneous set of sources, one was missing.
That left a bunch of source files and a file called 'makefile'.

> Normally you should call your makefile either makefile or Makefile.

This is what I mean. No, you shouldn't.

Suppose you accidentally copy 'makefile' from elsewhere? You wouldn't be
able to tell; they're all called Bob!

[Keith Thompson]

David Brown <david...@hesbynett.no> writes:
[...]

> Sure. But if you want to do that, you read the relevant sections of
> the manual and see which files you need, which options you want, what
> configuration you want, and how you should combine it with your own
> code. You need to know how to integrate Lua with your code - how your
> application will start the Lua runtime or call Lua code, how the Lua
> code will call /your/ functions (in C or whatever), how to wrap your
> functions, variables, classes, etc., into Lua tables and
> functions. There is a lot involved here - it's not a "download and
> compile" task. But then, you wouldn't be doing this unless you
> actually wanted to use Lua in your program and are willing to invest
> the effort to do so.

And none of that requires building Lua from source.

[Ben Bacarisse]

Bart <b...@freeuk.com> writes:

> 'make' must be unique in being an application that takes input from a file,
> but the name of the file is hardcoded.

Not really. The input to make is something like a configuration file,
and lots of applications (in Unix land) read a configuration file
derived from the program name. bc reads .bcrc, fetchmail reads
.fetchmailrc and so on. Had the authors decided have make read a file
called .makerc it would look much like many others.

Of course, the makefile is something more than a simple configuration
file, but it's also more like one than the files make is operating on
that will be specified on the command line.

(I'm ignoring -f because being able to override the default does not
invalidate your comment.

> Maybe make was written by the same person who hardcoded a.out as an output
> filename. They missing a trick by not having a.c as the default input for a
> C compiler; that makes as much sense.

oh dear, I typed the above before reading this, but I'll post the
explanation anyway...

--
Ben.

[Bart]

On 16/08/2023 21:26, Ben Bacarisse wrote:
> Bart <b...@freeuk.com> writes:
>
>> 'make' must be unique in being an application that takes input from
a file,
>> but the name of the file is hardcoded.
>
> Not really. The input to make is something like a configuration file,
> and lots of applications (in Unix land) read a configuration file
> derived from the program name. bc reads .bcrc, fetchmail reads
> .fetchmailrc and so on. Had the authors decided have make read a file
> called .makerc it would look much like many others.

No, what make does with 'makefile' is not what I'd associate with
configuration data which:

* May be shared by, and is constant, across different deployments of the
program when applied to different inputs

* Controls how the application works, and has nothing about the user's
data (at best, program settings the user has made which will carry over
into the next invocation)

* Is separate from the real user-supplied data for the application

For example, I had an application called M7.EXE, and it used (among
several config files), one called M7.INI that is read automatically.

But when M7 is invoked, it can be given the name of a real data file.

I don't have to copy my data (in this case a 3D data model) into M7.INI!

>> Maybe make was written by the same person who hardcoded a.out as an
output
>> filename. They missing a trick by not having a.c as the default
input for a
>> C compiler; that makes as much sense.
>
> oh dear, I typed the above before reading this, but I'll post the
> explanation anyway...

And I posted a civil reply anyway despite your snide remark.

Yes, some of these programs do look like the early efforts of a
beginning programmer. Decades later, people (even you) try to
rationalise their behaviour.

I just say it like it is.

[Richard Harnden]

On 16/08/2023 22:25, Bart wrote:
> On 16/08/2023 21:26, Ben Bacarisse wrote:
> > Bart <b...@freeuk.com> writes:
> >
> >> 'make' must be unique in being an application that takes input from
> a file,
> >> but the name of the file is hardcoded.
> >
> > Not really.  The input to make is something like a configuration file,
> > and lots of applications (in Unix land) read a configuration file
> > derived from the program name.  bc reads .bcrc, fetchmail reads
> > .fetchmailrc and so on.  Had the authors decided have make read a file
> > called .makerc it would look much like many others.
>
> No, what make does with 'makefile' is not what I'd associate with
> configuration data which:
>
> * May be shared by, and is constant, across different deployments of the
> program when applied to different inputs
>
> * Controls how the application works, and has nothing about the user's
> data (at best, program settings the user has made which will carry over
> into the next invocation)
>
> * Is separate from the real user-supplied data for the application
>

You know this is not what makefiles are for.

I think you're just being wrong on purpose.

[Bart]

Somebody compared the 'makefile' of 'make' to a configuration file of an
aplication.

I'm saying no, configuration files are different; they do this. So
clearly I was not saying that's what makefiles do.

So maybe /you're/ wrong being wrong on purpose just to make me look bad.

Please stop it.

[Ben Bacarisse]

Bart <b...@freeuk.com> writes:

> On 16/08/2023 21:26, Ben Bacarisse wrote:
>> Bart <b...@freeuk.com> writes:
>>
>>> 'make' must be unique in being an application that takes input from a
> file,
>>> but the name of the file is hardcoded.
>>
>> Not really. The input to make is something like a configuration file,
>> and lots of applications (in Unix land) read a configuration file
>> derived from the program name. bc reads .bcrc, fetchmail reads
>> .fetchmailrc and so on. Had the authors decided have make read a file
>> called .makerc it would look much like many others.
>
> No, what make does with 'makefile' is not what I'd associate with
> configuration data which:
>
> * May be shared by, and is constant, across different deployments of the
> program when applied to different inputs

You mean like a makefile?

> * Controls how the application works, and has nothing about the user's data
> (at best, program settings the user has made which will carry over into
> the next invocation)

That's a curious restriction! So a makefile with only general rules and
settings qualifies? But as soon as it mentions any specific file it
stops being "somewhat like" a configuration file (which is all I
claimed)?

> * Is separate from the real user-supplied data for the application

Too vague for me. What is separate? What is the unreal data?

Anyway, I did not expect to convince you. I hope you enjoyed
considering a perspective that differs from your own.

> I just say it like it is.

You say it like you see it (as do I). To consider that as "like it is"
takes more self confidence than I can muster.

--
Ben.

[Michael S]

On Wednesday, August 16, 2023 at 1:52:46 PM UTC+3, David Brown wrote:
> Certainly embedding it within other applications is a major purpose of
> the language, yes. It is becoming more mature as a stand-alone
> language, with more libraries, but it is very popular for adding to
> other programs. As you say, Lua is a common choice for scripting in
> games. I used it myself as a scripting language in an embedded program,
> many moons ago.

Did it work?
I mean, not an easy technical part of embedding an interpreter.
Did the "human" part work? Did people that were supposed to write
scripts bothered to learn the language and to start writing?

[Bart]

Configuration files for me are more like this:


APPLICATION < -- > USER DATA
^
|
v
[CONFIG FILE]

Config data is more like meta-data. (Maybe, a little like cookies used
by a program within a website; say one used to format user-supplied XML
data.)

It is not the primary data of the application.

For Make, the makefile /is/ the primary data. It belongs at that top
right. And it deserves a proper name.

Any configuration files are unlikely to have variable, user-provided names.

I think you were justifying Make using mainly fixed, hardcoded names for
its primary data, by classifying that data as configuration. I don't buy
it. That would make Make even more peculiar.

(What next, build Make from source with your project files listed in the
source code?)

>
> Anyway, I did not expect to convince you. I hope you enjoyed
> considering a perspective that differs from your own.
>
>> I just say it like it is.
>
> You say it like you see it (as do I). To consider that as "like it is"
> takes more self confidence than I can muster.

Make seems to mostly use a local file called 'makefile' for its primary
data. Certainly that's what it will use if no alternate is provided.

That's like 'it is'.

I have a Python benchmark where the input file name is hardcoded in the
source code. There's a comment to adjust that name to suit (or people
can use the same name for their own data). I couldn't be bothered to
process argv parameters.

Make is pretty much at that level.

[David Brown]

On 16/08/2023 19:07, Bart wrote:
> On 16/08/2023 14:16, David Brown wrote:
> > Tell me what you see as the advantage here, and why /you/ think it would
> > be a jolly good idea, and maybe I'll agree.  But you have to say why it
> > would be better for everyone, not just for you personally - you need
> > good reasons to change 50 year old conventions.
>
> [Giving names to makefiles]
>
> * You can have more than one project in the same folder

Makefiles can have multiple targets - that is, in fact, very common.
But usually it's a bad idea to have multiple different projects in the
same folder.

>
> * You can have different configurations of the same project

I do that all the time with a single makefile.

>
> * You can have different makefiles customised to different compilers
>   (Seed7 has nearly 20 different makefiles)

You can do that with a single makefile.

>
> * You can split up a project into components with their own separately
>   invoked makefile

You can do that with a single main makefile, and invoke submakes with
different makefiles if you like. Typically, these components and their
makefiles are in different subdirectories.

>
> * You can differentiate between a makefile that is called directly,
>   and one that is called indirectly from another

Call the main one "makefile", and the other one "other_bit.mak" - this
is fine and perfectly normal.

>
> * If you expected to build X according to the build instructions,
>   but the makefile is called Y, then you know something may be wrong

So making things more difficult for the user, flouting decades-old
conventions and expectations, is a good thing in your eyes?

>
> 'make' must be unique in being an application that takes input from a
> file, but the name of the file is hardcoded.

The /default/ file name is hardcoded (well, both "makefile" and
"Makefile" are supported). But as I mentioned before, if you want a
different name just use "make -f other_file_name". (Use a file
extension of your choice, if you want - make does not care.)

>
> A few applications will use defaults when a filename is missing (even if
> it's 'stdin'), but are generally used with a specific name.
>

For some programs it is common practice - such as for "make". And also,
I believe, for "CMake", "ant", "bake", "nmake", and all other build
tools I have seen. Basically, people building a project find it really
easy to go to the project directory and type "make" (or whatever).
Typing "make -f project_name.mk" would be an unnecessary inconvenience.
But of course you are free to do that if you want.

> I would actually make a missing filename an error for an application
> like this.
>
> Maybe make was written by the same person who hardcoded a.out as an
> output filename. They missing a trick by not having a.c as the default
> input for a C compiler; that makes as much sense.
>

I think you should get some experience with project organisation and
build tools - then you will understand better. Otherwise, just accept
that the way these things are done by other people makes a lot of sense
to everyone else.

[David Brown]

On 16/08/2023 21:55, Keith Thompson wrote:
> David Brown <david...@hesbynett.no> writes:
> [...]
>> Sure. But if you want to do that, you read the relevant sections of
>> the manual and see which files you need, which options you want, what
>> configuration you want, and how you should combine it with your own
>> code. You need to know how to integrate Lua with your code - how your
>> application will start the Lua runtime or call Lua code, how the Lua
>> code will call /your/ functions (in C or whatever), how to wrap your
>> functions, variables, classes, etc., into Lua tables and
>> functions. There is a lot involved here - it's not a "download and
>> compile" task. But then, you wouldn't be doing this unless you
>> actually wanted to use Lua in your program and are willing to invest
>> the effort to do so.
>
> And none of that requires building Lua from source.
>

It might do. But it won't use the plain build instructions.

For some uses, you can probably use a prebuilt lua runtime library. In
other cases, you /do/ want to build the source - but you are not
building the normal "lua" and "luac" programs. You are building object
files as part of your main application, with whatever configuration you
want for the lua parts. For example, lua normally uses 64-bit integers
as its only integer type, while in an 32-bit embedded system you might
prefer to use 32-bit integers in your embedded lua. And of course you'd
be using a cross-compiler, not a host compiler.

[David Brown]

Yes, at least for some simple cases. But those people were just me in
that particular case - I used Lua as a convenient way to write hardware
test scripts for the system. I haven't actually made much use of it
since, and that project was cancelled (nothing to do with lua or any of
the electronics or software - the mechanics were too expensive).
However, it is definitely something I would use again if I felt that
something more than a very simple command-line interface were useful in
an embedded project, and the hardware was big enough to support the
overhead (something like 60-70 KB code, IIRC).

[Scott Lurndal]

Michael S <already...@yahoo.com> writes:
>On Wednesday, August 16, 2023 at 1:52:46=E2=80=AFPM UTC+3, David Brown wrot=
>e:
>> Certainly embedding it within other applications is a major purpose of=20
>> the language, yes. It is becoming more mature as a stand-alone=20
>> language, with more libraries, but it is very popular for adding to=20
>> other programs. As you say, Lua is a common choice for scripting in=20
>> games. I used it myself as a scripting language in an embedded program,=
>=20

>> many moons ago.
>
>Did it work?
>I mean, not an easy technical part of embedding an interpreter.
>Did the "human" part work? Did people that were supposed to write
>scripts bothered to learn the language and to start writing?

We also have some stand-alone[*] software that runs on our CPUs
that uses an embedded lua interpreter. Users have had no problems
with it at all.

[*] in this context, bare-metal sans OS.

[Michael S]

Who are users in this case?

[Bart]

On 16/08/2023 14:16, David Brown wrote:

> On 16/08/2023 13:15, Bart wrote:
> Then there is the question of why it matters. PC disks are big. PC
> CPUs are fast. Network speeds are high. Top quality development tools
> and utilities are freely available - even on Windows. Size and speed
> matters very little for software on PC's. (It matters a great deal on
> small embedded systems.)

And yet... when I reinstalled CMake, it took nearly 10 minutes to unzip
7300 files into 112MB, on an SSD. I don't why it took that long, but it did.

(There's also the mystery of why it takes such a humungous program to
... turn a file-spec info into a makefile? I could do that by hand in
less than 10 minutes! In the end CMake couldn't even complete the task:
maybe 7300 files wasn't quite enough.

But I think you're not keen on CMake anyway.)

When I tried to install VS once, although on an older machine with a
hard drive, it took 90 minutes. Each time it started up (usually
inadvertently because of a file association), it took 90 seconds.

On the same machine, my programs started instantly.

>
> So who are you fighting for? Who are you fighting against? Do you
> really think you are making a difference for some greater good here, or
> even just for your own personal benefit?

There are a huge number of benefits to keeping things small and
managable. You don't understand what they are because of using top-end
hardware, and using systems and tools that many people use in your field
so that things run smoothly; an issues will have been fixed or patches.

Lots of people have also piled on extra complexity to get around
problems of sluggishness: being extra clever in avoiding repeating the work.

Or just throwing an extra 31 cores at the problem.

> (There's nothing wrong with
> doing it for your own benefit - I am not suggesting you have to fight
> for other people.)

This is an analogy I have used before regarding LLVM, which is a backend
for language implementations. It is quite large and complex.

Once I needed a side-gate for my house. I made it myself, and ended up
with a 6' high wooden gate, of just the right size.

Now if I'd gone to the LLVM shop as a solution, the gate would have been
9 miles high - if I could ever figure it out.

> Have you considered whether there are other battles
> that would make more sense or have greater impact? Have you considered
> forgetting it all, splashing out £300 on a new mini-PC, installing Linux
> Mint, and going back to having fun with computers, learning new things,
> and creating software without bothering about how much space gcc
takes up?

Lots of people are having fun with retrocomputing, where they can be 99%
responsible for what's going on rather than 1%. And there is it can
challenging, in a fun way, to have limits on what is possible.

However, you're wrong about space ceasing to be an issue: devices such
as smartphones, despite having GBs of storage rapidly get filled up
because every downloaded app is 10s of MB and sometimes 100s.

Because nobody cares anymore.

>>
>> Of course, you are NEVER going to admit that doing:
>>
>> mm lua
>>
>> might be a touch sweeter than those 330 lines of makefile crap below.
>
> I fail to see how that's better than "make" (or "make mingw" on
> Windows).

And here is the crux. You really believe that you can solve 'complexity'
by hiding it away in a box and providing one simple launch button.

My preference is to tackle complexity by actually (gasp!) making it
simpler not just piling on even more stuff.

(Here's the David Brown approach to editing a messy 10,000-page draft of
a book down to 500 pages: just print it in a smaller font to fit into
500 pages; easy!

Or publish it on Kindle: nobody has a clue how long anything is on one
of those anyway. It will just take ages to get from 0% to 1%.

You might object, but this is exactly what happens with software: there
we now have unlimited amounts of program memory, and NOBODY apparently
cases about size, bloat, inefficiency and gratuitous complexity.

Well, until it comes to the difference between say Tcc and gcc/LLVM,
where 99% of the latter's build time is spent making programs twice as
fast as with the 180KB tcc.exe.

Then that mere 2.0 factor becomes hugely important, it cutting down
lesser compilers down to size.

> I /do/ see how "make" is vastly superior, because the
> makefile has lots more in it than just the dependencies that could be
> found automatically. Where does "mm lua" put all the compiler flags?

If you wanted to build my 'qq' interpreter, I could provide these three
files:

c:\demo>dir
17/08/2023 16:51 17 makefile
17/08/2023 16:54 438,272 mm.exe
17/08/2023 16:52 581,891 qq.ma

Unlike a normal source bundle, I provide the compiler needed. This is
one of many advantages of a small self-contained compiler. The source
files have also been bundled into one file.

The makefile contains this:

qq:
mm qq.qa

(I can't test it because make disappeared with gcc. I tried downloading
one but it had missing DLLs. So, forget it.)

So to build, you can either do:

make # needs 'make' installed

or:

mm qq.qa

Satisfied? My compiler is intrinsically simple. The end result is a
working interpreter.

[Scott Lurndal]

Michael S <already...@yahoo.com> writes:
>On Thursday, August 17, 2023 at 7:01:51=E2=80=AFPM UTC+3, Scott Lurndal wro=
>te:
>> Michael S <already...@yahoo.com> writes:=20
>> >On Wednesday, August 16, 2023 at 1:52:46=3DE2=3D80=3DAFPM UTC+3, David B=
>rown wrot=3D=20
>> >e:=20

>> >> Certainly embedding it within other applications is a major purpose of=

>=3D20=20
>> >> the language, yes. It is becoming more mature as a stand-alone=3D20=20
>> >> language, with more libraries, but it is very popular for adding to=3D=
>20=20
>> >> other programs. As you say, Lua is a common choice for scripting in=3D=
>20=20
>> >> games. I used it myself as a scripting language in an embedded program=
>,=3D=20
>> >=3D20
>> >> many moons ago.=20
>> >=20
>> >Did it work?=20
>> >I mean, not an easy technical part of embedding an interpreter.=20
>> >Did the "human" part work? Did people that were supposed to write=20

>> >scripts bothered to learn the language and to start writing?

>> We also have some stand-alone[*] software that runs on our CPUs=20
>> that uses an embedded lua interpreter. Users have had no problems=20
>> with it at all.=20
>>=20

>> [*] in this context, bare-metal sans OS.
>
>Who are users in this case?

Firmware engineers, customer field support engineers and in some
cases, customers.